Skip site navigation (1) Skip section navigation (2)

Re: Compressing the AFTER TRIGGER queue

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Compressing the AFTER TRIGGER queue
Date: 2011-08-01 19:48:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

> 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.


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-08-01 19:53:19
Subject: Re: Compressing the AFTER TRIGGER queue
Previous:From: Merlin MoncureDate: 2011-08-01 19:37:22
Subject: Re: Access to current database from C-language function

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group