From: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Set visibility map bit after HOT prune |
Date: | 2012-12-20 18:00:35 |
Message-ID: | CABOikdNw3V_inSyfKCty+yEtDdvb0ePg0i+hYbYC2w+x3PNRYA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 20, 2012 at 10:59 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Dec 20, 2012 at 11:49 AM, Pavan Deolasee
> <pavan(dot)deolasee(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | John R Pierce | 2012-12-20 18:18:34 | Re: pg_top |
Previous Message | Pavan Deolasee | 2012-12-20 17:49:27 | Re: Set visibility map bit after HOT prune |