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

Re: Compressing the AFTER TRIGGER queue

From: Jim Nasby <jim(at)nasby(dot)net>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-03 22:05:21
Message-ID: 4B502D16-0C61-408F-8664-AA432FD0A3DA@nasby.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Aug 2, 2011, at 7:09 AM, Simon Riggs wrote:
>>  The best compression and flexibility in
>>> that case is to store a bitmap since that will average out at about 1
>>> bit per row, with variable length bitmaps. Which is about 8 times
>>> better compression ratio than originally suggested, without any loss
>>> of metadata.
>> 
>> Yeah that's probably possible in specific cases, but I'm still not
>> sure how to make it meet the full requirements of the after trigger
>> queue.
> 
> I think you'd better explain what use case you are trying to optimise
> for. It seems unlikely that you will come up with a compression scheme
> that will fit all cases.
> 
> The only cases that seem a problem to me are
> * bulk RI checks
> * large writes on tables using trigger based replication
> maybe you have others?

Not sure how much this relates to this discussion, but I have often wished we had AFTER FOR EACH STATEMENT triggers that provided OLD and NEW recordsets you could make use of. Sometimes it's very valuably to be able to look at *all* the rows that changed in a transaction in one shot.
--
Jim C. Nasby, Database Architect                   jim(at)nasby(dot)net
512.569.9461 (cell)                         http://jim.nasby.net



In response to

Responses

pgsql-hackers by date

Next:From: Jim NasbyDate: 2011-08-03 22:21:53
Subject: Re: mosbench revisited
Previous:From: Tom LaneDate: 2011-08-03 21:57:35
Subject: Re: Locking end of indexes during VACUUM

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