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: | CAEZATCW5A47-hog46kOwtSXJf-fwkQfmnVp=OfiS_53B85bH_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-08-01 17:08:23 | Re: One-Shot Plans |
Previous Message | Tom Lane | 2011-08-01 16:49:08 | Re: Compressing the AFTER TRIGGER queue |