Re: Hot standby and b-tree killed items

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: Re: Hot standby and b-tree killed items
Date: 2008-12-24 15:45:52
Message-ID: 1230133552.4793.1155.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Wed, 2008-12-24 at 09:59 -0500, Robert Treat wrote:

> I think the uncertainty comes from peoples experience with typical replication
> use cases vs a lack of experience with this current implementation.

Quite possibly.

Publishing user feedback on this will be very important in making this a
usable feature.

I'd be very happy if you were to direct the search for optimal
usability.

> One such example is that it is pretty common to use read-only slaves to do
> horizontal scaling of read queries across a bunch of slaves. This is not the
> scenario of running reporting queries on a second machine to lower load; you
> would be running a large number of read-only, relativly short, oltp-ish
> queries (think pg_benchs select only test i suppose), but you also have a
> fairly regular stream of inserts/updates going on with these same tables, its
> just you have 95/5 split of read/write (or similar).

One thing to consider also is latency of information. Sending queries to
master or slave may return different answers if querying very recent
data.

> This is standard practice in things like mysql or using slony or what have
> you. I suspect it's one of the first things people are going to want to do
> with hot standby. But it's unclear how well this will work because we don't
> have any experience with it yet, coupled with the two downsides being
> mentioned as canceled queries and replay lag, which happen to be probably the
> two worst downsides you would have in the above scenario. :-)
>
> Hmm.... I'm not sure why I didn't think of running this test before, but
> read/write pg_bench on a master with pg_bench select test on slave isn't that
> bad of a scenario to match the above; it might be a little too much activity
> on the master, but has anyone else run such a test?
>
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2008-12-24 16:12:33 Re: [idea] a copied relkind in pg_attribute
Previous Message Emmanuel Cecchet 2008-12-24 15:41:44 Re: [Fwd: Re: Transactions and temp tables]