"Tom Lane" <[EMAIL PROTECTED]> writes: > The argument that Heikki actually made was that multiple parallel > queries could use more of the I/O bandwidth of a multi-disk array > than recovery could. Which I believe, but I question how much of a > real-world problem it is. For it to be an issue, you'd need a workload > that is almost all updates (else recovery wins by not having to > replicate reads of pages that don't get modified) and the updates have > to range over a working set significantly larger than physical RAM > (else I/O bandwidth won't be the bottleneck anyway). I think we're > talking about an extremely small population of real users.
Of course that describes most benchmarks pretty well... I think of this as a scalability problem, not so much a sheer speed problem. If Postgres isn't fast enough for you you should be able to buy a faster processor or faster disk or faster something to run it faster. The problem with this situation is that buying a faster raid controller doesn't help you. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---------------------------(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
