Re: Best replication solution? - Mailing list pgsql-performance

From Jeff
Subject Re: Best replication solution?
Date
Msg-id 77A7A940-78F9-4729-A28E-44270CB7C330@torgo.978.org
Whole thread Raw
In response to Re: Best replication solution?  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-performance
On Apr 8, 2009, at 4:46 PM, Dimitri Fontaine wrote:

>
> $ londiste.py setup.ini provider add schema.table
> $ londiste.py setup.ini subscriber add schema.table
>

That is nice.  One could probably do that for slony too.

I may try some tests out with londiste.. I'm always open to new
(ideally, better) things.
>
> This could happen in Londiste too, just set pgq_lazy_fetch to a
> reasonable value and Londiste will use a cursor to fetch the events,
> lowering the load. Events are just tuples in an INSERT only table,
> which when not used anymore is TRUNCATEd away. PGQ will use 3 tables
> where to store events and will rotate its choice of where to insert
> new envents, allowing to use TRUNCATE rather than DELETE. And
> PostgreSQL is quite efficient to manage this :)
>  http://wiki.postgresql.org/wiki/Londiste_Tutorial#Londiste_is_eating_all_my_CPU_and_lag_is_raising
>

Well, Slony always uses a cursor to fetch, the problem is it may have
to slog through millions of rows to find the new data - I've analyzed
the queries and there isn't much it can do -  lots of calls to the
xxid_ functions to determine whats to be used, whats not to be used.
When all slaves have a sync event ack'd it is free to be removed by
the cleanup routine which is run every few minutes.

>
> Oh and some people asked what Londiste with failover and DDL would
> look like. Here's what the API being cooked looks like at the moment:
> $ londiste setup.ini execute myddl.script.sql
>
> $ londiste conf/londiste_db3.ini change-provider --provider=rnode1
> $ londiste conf/londiste_db1.ini switchover --target=rnode2
>

ok, so londiste can't do failover yet, or is it just somewhat
convoluted at this point?

--
Jeff Trout <jeff@jefftrout.com>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/




pgsql-performance by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Nested query performance issue
Next
From: Mark Wong
Date:
Subject: linux deadline i/o elevator tuning