Syd <[EMAIL PROTECTED]> writes: > However, with postgres 7.4 on Mac OSX 10.2.3, we're getting an amazing > 500 inserts per second.
> We can only put this down to the OS. As noted elsewhere, it's highly likely that this has nothing to do with the OS, and everything to do with write caching in the disks being used. I assume you are benchmarking small individual transactions (one insert per xact). In such scenarios it's essentially impossible to commit more than one transaction per revolution of the WAL disk, because you have to write the same WAL disk page repeatedly and wait for it to get down to the platter. When you get results that are markedly in excess of the disk RPM figure, it's proof positive that the disk is lying about write complete (or that you don't have fsync on). The only way to get better performance and still have genuine ACID behavior is to gang multiple insertions per WAL write. You can do multiple insertions per transaction, or if you are doing several insertion transactions in parallel, you can try to commit them all in one write (experiment with the commit_delay and commit_siblings parameters). > BTW, on the same hardware that postgres is running on to get 50 inserts > per sec, MySQL (4.0.17) is getting an almost unbelievable 5,500 inserts > per second. I'll bet a good lunch that MySQL is not being ACID compliant in this test. Are you using a transaction-safe table type (InnoDB) and committing after every insert? If you don't in fact care about ACID safety, turn off fsync in Postgres so that you have an apples-to-apples comparison (or at least apples-to-oranges rather than apples-to-cannonballs). regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html