Hi,

I apologize if this is the wrong list to post these questions.

1. Does Slony replicate table statistics to the slaves?
2. Do you still have to vacuum analyze the slaves?
3. Are selects replicated or just inserts, updates, and deletes?
4. I'd like to have our updates go to the master and selects go to
the clients. Is that possible?
5. What happens if an update tries to go to the slave? Does it
automatically get routed to the master?

Thanks,

__________________________________________________ __________________
Brendan Duddridge | CTO | 403-277-5591 x24 | brendan@clickspace.com

ClickSpace Interactive Inc.
Suite L100, 239 - 10th Ave. SE
Calgary, AB T2G 0V9

http://www.clickspace.com

On Tuesday 30 May 2006 21:13, Brendan Duddridge <brendan@clickspace.com>
wrote:
> Hi,
>
> I apologize if this is the wrong list to post these questions.
>

There is a Slony list, but I'm sure there's some overlap

> 1. Does Slony replicate table statistics to the slaves?

No.

> 2. Do you still have to vacuum analyze the slaves?

Yes. All a subscriber basically is, is an otherwise normal PostgreSQL
database that a Slony process happens to write data into.

> 3. Are selects replicated or just inserts, updates, and deletes?

Replication actions are scheduled on a row-level basis, via trigger, for
each row inserted, updated, or deleted. Those actions are executed in an
intelligent manner on the subscribers. Additional events, such as DDL
modification scripts, can also be scheduled.

However, to answer the question, just inserts, updates, and deletes.

> 4. I'd like to have our updates go to the master and selects go to
> the clients. Is that possible?

Yep ... while keeping in mind that it is an asynchronous replication system,
and the subscribers will not generally be in perfect sync with the master.
You will need separate database connections since the setup doesn't appear
as a single cluster or anything like that.

> 5. What happens if an update tries to go to the slave? Does it
> automatically get routed to the master?

Tables on the subscribers are modified to prevent write ops. The subscriber
table otherwise has no knowledge of the master. Operations are therefore
not re-routable.

I would strongly suggest setting up a test replication setup to learn
exactly how Slony works before deciding on a particular architecture.

--
"When a politician says he wants you to serve a cause greater than your
own self-interest, the cause he has is mind is his own reelection."

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

> 4. I'd like to have our updates go to the master and selects go to
> the clients. Is that possible?
You can use pgpool to achieve this (http://pgpool.projects.postgresql.org/).

Hayee

On 5/31/06, Alan Hodgson <ahodgson@simkin.ca> wrote:
>
> On Tuesday 30 May 2006 21:13, Brendan Duddridge <brendan@clickspace.com>
> wrote:
> > Hi,
> >
> > I apologize if this is the wrong list to post these questions.
> >
>
> There is a Slony list, but I'm sure there's some overlap
>
> > 1. Does Slony replicate table statistics to the slaves?
>
> No.
>
> > 2. Do you still have to vacuum analyze the slaves?
>
> Yes. All a subscriber basically is, is an otherwise normal PostgreSQL
> database that a Slony process happens to write data into.
>
> > 3. Are selects replicated or just inserts, updates, and deletes?
>
> Replication actions are scheduled on a row-level basis, via trigger, for
> each row inserted, updated, or deleted. Those actions are executed in an
> intelligent manner on the subscribers. Additional events, such as DDL
> modification scripts, can also be scheduled.
>
> However, to answer the question, just inserts, updates, and deletes.
>
> > 4. I'd like to have our updates go to the master and selects go to
> > the clients. Is that possible?
>
> Yep ... while keeping in mind that it is an asynchronous replication
> system,
> and the subscribers will not generally be in perfect sync with the master.
> You will need separate database connections since the setup doesn't appear
> as a single cluster or anything like that.
>
> > 5. What happens if an update tries to go to the slave? Does it
> > automatically get routed to the master?
>
> Tables on the subscribers are modified to prevent write ops. The
> subscriber
> table otherwise has no knowledge of the master. Operations are therefore
> not re-routable.
>
> I would strongly suggest setting up a test replication setup to learn
> exactly how Slony works before deciding on a particular architecture.
>
> --
> "When a politician says he wants you to serve a cause greater than your
> own self-interest, the cause he has is mind is his own reelection."
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>