On Mon, Aug 1, 2011 at 1:42 PM, Dean Rasheed <dean.a.rash...@gmail.com> wrote: >>> Hmmmm ... not sure. It seems a bit scary, but on the other hand we >>> should be able to assume that the updating subtransaction hasn't been >>> rolled back (else surely we shouldn't be firing the trigger). So in >>> principle it seems like the t_ctid link can't have been replaced. >>> This will foreclose any ideas about collapsing t_ctid link chains, >>> if anyone had it in mind to do that. >> >> 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. I worry a bit that this might foreclose possible future optimization of the "self update" case, which is a known pain point. Am I wrong to worry? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
