From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Geographic High-Availability/Replication |
Date: | 2007-08-29 00:24:21 |
Message-ID: | 20070829002421.GQ1386@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Aug 24, 2007 at 06:54:35PM +0200, Markus Schiltknecht wrote:
> Gregory Stark wrote:
> >Only if your application is single-threaded. By single-threaded I don't
> >refer
> >to operating system threads but to the architecture. If you're processing a
> >large batch file handling records one by one and waiting for each commit
> >before proceeding then it's single threaded. If you have a hundred
> >independent
> >clients on separate connections doing separate things then each one of them
> >could get 6tps. Which you have will depend on your application and your
> >needs,
> >it may not be something you can change.
>
> Correct.
>
> Plus, as in the implementation of Postgres-R, performance is *not* bound
> to the slowest node. Instead, every node can process transactions at
> it's own speed. Slower nodes might then have to queue transactions from
> those until they catch up again.
But is the complete transaction information safely stored on all nodes
before a commit returns?
--
Decibel!, aka Jim Nasby decibel(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | D. Dante Lorenso | 2007-08-29 00:24:42 | Re: Is there a better way to do this? |
Previous Message | Decibel! | 2007-08-29 00:16:20 | Re: Seeking datacenter PITR backup procedures [RESENDING] |