Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > > Hi, > > 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.
I'm curious as to how Postgres-R would handle a situation where the constant throughput exceeded the processing speed of one of the nodes. I can see your system working if it's just spike loads and the slow nodes can catch up during slow periods, but I'm wondering about the scenarios where an admin has underestimated the hardware requirements and one or more nodes is unable to keep up. Just musing, really. -- Bill Moran http://www.potentialtech.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
