On 1 August 2011 19:56, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> On 1 August 2011 18:55, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Aug 1, 2011 at 1:42 PM, Dean Rasheed <dean.a.rash...@gmail.com> >> wrote: >>>> Don't we already do that when pruning HOT chains? > >>> I thought that only happens after the transaction is committed, and >>> old enough, whereas the trigger code only needs to follow the chain in >>> the updating transaction. > >> Hmm, true. > > On reflection I think we're probably worrying over nothing. The only > way that the t_ctid link might have gotten changed (given that the > original updating subtransaction hasn't been aborted) is if we were > willing to prune an inserted-and-then-deleted-in-same-xact tuple out of > the t_ctid link chain while its parent xact is still running. However, > it is unsafe to do that unless you know for certain that the xact in > question has no snapshots that could see the tuple as live. VACUUM > certainly doesn't know that, and neither does pruneheap.c, and I don't > really foresee us introducing enough bookkeeping so that they would know > it. (If we did try to do that, we could handle the problem by > considering that queueing of trigger events introduces a quasi-snapshot > that requires the relevant tuples to remain available.) > > So I think this is probably OK as long as it's adequately documented in > the code. Just for luck, though, we should add an xmin/cmin match check > to the code if there's not one already. >
I don't see any such existing check. Is this the same as checking that xmax/cmax on the old tuple matches xmin/cmin on the linked-to tuple? If so, that's pretty straightforward. Otherwise I'm not sure where the xmin/cmin to check against would come from, without adding more information to the queues somewhere. > However, this means that Dean is not simply adding some self-contained > compression logic; he's eliminating information from the data structure > on the grounds that he can get it from elsewhere. I think that that > ought to be treated as a separate patch, and that the costs/benefits > of the "compressed" data structure ought to be evaluated relative to the > situation with the second CTID removed but the data structure not > otherwise changed. > OK, so I should split this into 2 patches? Even without the compression, it's probably worth the 16 -> 10 byte reduction that would result from removing the 2nd CTID in the UPDATE case, and that part would be a pretty small patch. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
