On Nov 24, 2007 5:16 PM, Gregory Stark <stark@enterprisedb.com> 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