Pavan Deolasee <pavan.deola...@gmail.com> writes:
> On Sun, Dec 16, 2012 at 3:10 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> As explained above, I disagree that it looks like a good idea, and
>> you've shown no evidence it would be or is true.
> Lets separate out these two issues. What you are suggesting as a
> follow up to Tom's idea, I've no objection to that and that might be
> worthwhile optimisation to try out. But this patch itself does not
> attempt to deal with that and its a separate work item and will
> require invasive changes and tests.
> *Whenever* we HOT prune, either in SELECT path or UPDATE path, what
> I'm suggesting is lets try to set the visibility map bit if the
> conditions are favorable.
I don't believe it's clear at all that this is a good idea. If we
restrict pruning to occur only when there's a fairly good chance of
an ensuing HOT update, then Simon's original objection (that we're
probably going to have to clear the bit again right away) has
considerable force. And I agree with him that your proposed
redefinition of the bit's meaning to avoid that is pretty horrid;
it's ugly, complicates the invariant quite a lot, and breaks some
existing usages of the bit.
If we decide that we don't want to restrict pruning like that, then
this patch probably has merit. But we can't evaluate the two issues
independently.
Another thing that would need to be considered, if we do want to
restrict when pruning happens, is whether it is worth introducing some
other path altogether for setting the all-visible bit. Or perhaps we
should modify autovacuum's rules so that it will fire on relations for
which there might be lots of unmarked all-visible pages.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
