On Nov 24, 2007 5:16 PM, Gregory Stark <[EMAIL PROTECTED]> wrote: > This is a conflict which will affect Postgres in the future as well. Generally > I/O costs win over cpu costs in databases since only relatively small systems > are cpu-bound. Large systems are typically I/O-bound.
It really depends on what you call a small system. In my current project, the database size is 4.6GB. So it's a small database in size which can fit in RAM. *But* it's a highly loaded database with a lot of complex queries (lots of joins, proximity queries and so on) and it's mostly CPU bound. And it's really a critical one. I'd really like to see us find a good compromise between CPU and I/O because CPU bound database aren't uncommon (especially for web usage). And they aren't less critical than I/O bound ones. And the most important point IMHO is that we must be aware of the trade-offs we make. We might have some cases where the CPU trade-off is not worth the I/O improvement (and probably the other case too). We really need a test framework to be able to perform daily benchmarks in various situations through the whole release cycle. I currently have compiled a version per month from january to now to perform my own tests (mostly CPU bound). If anyone wants me to perform specific pgbench load (I know it's not perfect but it's the most convenient tool we have currently), ping me. The box is only a Core2 duo box with 2 GB of RAM and a SATA disk. So it's quite easy to be I/O bound :). -- Guillaume ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq