Обсуждение: HeapTupleSatisfiesToast not setting XMIN_COMMITTED?
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? -- Álvaro Herrera <alvherre@alvh.no-ip.org>
On Wed, Sep 21, 2011 at 1:03 PM, Alvaro Herrera <alvherre@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. merlin
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 <alvherre@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. 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. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, Sep 21, 2011 at 2:14 PM, Alvaro Herrera <alvherre@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 <alvherre@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
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> 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?
Hmm ... I wonder if that has something to do with the performance
complaints we sometimes get about TOAST. VACUUM would presumably set
the bit, but in a never-vacuumed toast table this could be a problem.
regards, tom lane
Alvaro Herrera <alvherre@commandprompt.com> writes:
> 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.
I have some vague recollection that the only reason we do any xmin/xmax
checking at all for a TOAST tuple is to support tuple motion caused by
old-style VACUUM FULL. Jan might remember better.
regards, tom lane