On Wed, Sep 21, 2011 at 2:14 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > > Excerpts from Merlin Moncure's message of mié sep 21 16:02:34 -0300 2011: >> On Wed, Sep 21, 2011 at 1:03 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> >> wrote: >> > >> > Hi, >> > >> > I notice that HeapTupleSatisfiesToast is not setting the >> > HEAP_XMIN_COMMITTED bit, though it is reading it. Is there a reason for >> > this? It seems to me that it'd make sense to have it set ... unless >> > it's set by some other routine, somehow? >> >> I think it's implied from the untoasted row. Notice that it's not >> checking visibility either except in binary upgrade cases. > > Yeah, so toast visibility is highly dependant to the referencing row. > Which makes sense. But then, if the XMIN_COMMITTED bit is not set, > you're forced to check the other bits every time. I guess the tradeoff > is that if you set it, the page is dirtied and you're forced to write it > down, which is even worse.
yeah -- there's no way it's worth the i/o in that case, since there's no visibility check to protect yourself from. > More interesting, however, is the fact that the XMAX_COMMITTED bit is > never set either. I guess the rows are deleted by a different mechanism > (tuptoaster probably) -- it isn't obvious how this works just by looking > at tqual.c. It seems to do nothing at all. yup -- probably the only reason it exists at all is vacuum issues which all visibility routines have to handle. otherwise, it's a fancy 'return true'. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
