> I have a client who wants to add additional indexes on
> the read-only replica.
>
> Off hand, I don't see a problem with this.  They want
> faster access from those servers.  Is there any reason
> why this would not work or is a stupid idea?

I'd be a little hesitant if it would be a unique index, as that offers a
way for the replica to break down.  That's true in general for any way in
which you might add additional constraints on a replica.

But otherwise, there's no reason for this not to work, and we have some
cases where we throw extra indices on certain replicas.

We have tables that are "write only" as far as the production system is
concerned, and adding indices there would slow insertions while providing
no value.  (No value since we don't run reports that would use the indices
there...)

Reporting systems hitting against replicas certainly need the indices, and
there's no transactional SLAs there; a bit of extra latency hurts noone.

> Also, if anyone can give me a heads up regarding replicating
> volitile tables where large numbers are added and deleted
> often enough to screw up the planner.  Would this increase
> their need for constant vacuuming or something of that nature?

Question: To what degree do you get transactions rolled back in the
"master" system?

If substantially all transactions succeed, then replication will mean that
you need more or less as many vacuums and analyzes going on against the
replicas as on the "master."

On the other hand, if a lot of transactions get rolled back on the master,
that means the master sees a lot more "killed tuples" than is the case on
the replicas, which only see the updates that actually SUCCEED, and so
replicas should need somewhat less maintenance than the "master."
-- 
<http://linuxdatabases.info/info/slony.html>