Re: Compressing the AFTER TRIGGER queue

On 1 August 2011 19:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
>> On 1 August 2011 18:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Aug 1, 2011 at 1:42 PM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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