From: | Hannu Krosing <hannu(at)krosing(dot)net> |
---|---|
To: | Mike <mike(at)fonolo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: intercepting WAL writes |
Date: | 2008-05-29 06:57:53 |
Message-ID: | 1212044273.7129.12.camel@huvostro |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2008-05-28 at 19:11 -0400, Mike wrote:
>
> Can somebody point to the most logical place in the code to intercept
> the WAL writes? (just a rough direction would be enough)- or if this
> doesn’t make sense at all, another suggestion on where to get the
> data?
I don't think that intercepting (and then decoding ) WAL is very
productive. It is too low level to be of much help.
The way I'd do it would be using pgQ from SkyTools package where change
events can be queued when happening and then moved in bulk to memcached
with not too much effort.
Marko Kreen, the primary author of pgQ did a presentation on it at this
years pgcon :
http://www.pgcon.org/2008/schedule/events/79.en.html
You can download the presentation slides to get the overview.
> (I’m trying to avoid doing it using triggers).
I can't see a good point in avoiding triggers, if you end up doing a lot
more work to reconstruct the data which would have been easy to get
using a trigger.
I've heard that there was and add-on replication solution for Oracle
which extracted data from WAL and I was told that it maxed out at about
200 tps. pgQ approach can do much better.
---------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Sabbiolina | 2008-05-29 08:26:10 | [PERFORM] Memory question on win32 systems |
Previous Message | Hannu Krosing | 2008-05-29 06:44:34 | Re: BUG #4204: COPY to table with FK has memory leak |