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: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Compressing the AFTER TRIGGER queue
Date: 2011-08-01 17:00:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 1 August 2011 17:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
>> I've been thinking some more about the long-standing problem of the
>> AFTER TRIGGER queue using too much memory, and I think that the
>> situation can be improved by using some basic compression.
>> Currently each event added to the AFTER TRIGGER queue uses 10 bytes
>> per trigger per row for INSERTs and DELETEs, and 16 for UPDATEs. The
>> attached patch reduces this down to just 1 byte in a number of common
>> cases.
> Ummm ... I only read the data structure comments, not the code, but I
> don't see where you store the second CTID for an update event?

Ah yes, I forgot to mention that bit. I'm using
&(tuple1.t_data->t_ctid) to get the second CTID from the old tuple. Is
that safe? As far as I could see, this would match the new tuple after
a heap update.


In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-08-01 17:08:23
Subject: Re: One-Shot Plans
Previous:From: Tom LaneDate: 2011-08-01 16:49:08
Subject: Re: Compressing the AFTER TRIGGER queue

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