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@xxxxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment:
pgpbUp8X65dUW.pgp
Description: PGP signature
