On Thu, Dec 20, 2012 at 10:59 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Dec 20, 2012 at 11:49 AM, Pavan Deolasee > <pavan.deola...@gmail.com> wrote: >> I wonder if we should add a flag to heap_page_prune and try to do some >> additional work if its being called from lazy vacuum such as setting >> the VM bit and the tuple freeze. IIRC I had put something like that in >> the early patches, but then ripped of for simplicity. May be its time >> to play with that again. > > That seems unlikely to be a good trade-off. If VACUUM is going to do > extra stuff, it's better to have that in the vacuum-specific code, > rather than in code that is also traversed from other places. > Otherwise the conditional logic might impose a penalty on people who > aren't taking those branches. >
Thats a call we need to take between code duplication vs customising execution. We do that all over the code. Not sure if it will be any different here. > > It's unclear to me that that's the right way to slice it. There are > several different sets of concerns here: (1) avoiding setting the > all-visible bit when it'll be cleared again just after, (2) avoiding > slowing down SELECT with hot-pruning, and (3) avoiding slowing down > repeated SELECTs by NOT having the first one do HOT-pruning. And > maybe others. The right thing to do depends on which problems you > think are relatively more important. That question might not even > have one right answer, but even if it does we don't have consensus on > what it is. Hmm. We tossed and discussed many interesting ideas in this thread. It will be sad if none of them go anywhere. When I look at archives, I see we might have discussed some of these even in the past but never got an agreement because there always be a workload which may not be served well by any specific idea. And many a times, they are so interrelated that we either have to do all or none. Unfortunately, trying to do all is too-much and too-invasive most often. May be what we need an official experimental branch where such ideas can be checked-in and encourage people to try out those branches in their real world tests or set up dedicated benchmark machines to run regular tests. Tested and proven ideas can then be merged into the main trunk. That will be the only way to know efficacy of such ideas. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers