On Mon, 2010-10-11 at 15:22 -0400, Robert Haas wrote: > >> This is a completely separate issue from making replication > >> synchronous. And, really? Useless for running read queries? > > > > Absolutely. For a synch standby, you can't tolerate any standby delay > > at all. This means that anywhere from 1/4 to 3/4 of queries on the > > standby would be cancelled on any high-traffic OLTP server. Hence, > > "useless". > > What is your source for those numbers? They could be right, but I > simply don't know.
I was initially taken aback by the word "useless" as well. However, I had trouble thinking of a use case that isn't better solved by sync rep without HS, or async rep. I don't have the numbers either though, so perhaps someone does have a use case. > It would be far better if we could decouple master cleanup from > standby cleanup, so that only the machine that actually has the old > query gets bloated. However, no one seems excited about writing that > code. That doesn't seem just a matter of code, it seems like a major design conflict. If the master removes a tuple and then re-uses that space for another tuple, you can't move those changes to the standby unless you cancel queries dependent on the first tuple. > A further grump about our current architecture is that it doesn't seem > at all clear how to make it work for partial replication. I have to > wonder whether we are going down the wrong path completely and need to > hit the reset button. But neither this nor the pruning problem are > things that we can reasonably expect the sync rep patch to solve, if > we want it to get committed this release cycle. What we have is physical replication, but you seem to be talking about logical replication (evidence: Slony solves both the independent cleanup problem and partial replication). Both logical and physical replication have a place, and I don't believe either is the "wrong" path. If we'd like to add logical replication, we may be better of starting with Slony (or Londiste) and working from there. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers