On Thu, Oct 7, 2010 at 2:31 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Robert Haas <robertmh...@gmail.com> wrote: >> Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > >>> With web applications, at least, you often don't care that the >>> data read is absolutely up-to-date, as long as the point in time >>> doesn't jump around from one request to the next. When we have >>> used load balancing between multiple database servers (which has >>> actually become unnecessary for us lately because PostgreSQL has >>> gotten so darned fast!), we have established affinity between a >>> session and one of the database servers, so that if they became >>> slightly out of sync, data would not pop in and out of existence >>> arbitrarily. I think a reasonable person could combine this >>> technique with a "3 of 10" synchronous replication quorum to get >>> both safe persistence of data and reasonable performance. >>> >>> I can also envision use cases where this would not be desirable. >> >> Well, keep in mind all updates have to be done on the single >> master. That works pretty well for fine-grained replication, but >> I don't think it's very good for full-cluster replication. > > I'm completely failing to understand your point here. Could you > restate another way?
Establishing an affinity between a session and one of the database servers will only help if the traffic is strictly read-only. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
