Syd <569170(at)aliencamel(dot)com> 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
> 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
In response to
pgsql-performance by date
|Next:||From: Rigmor Ukuhe||Date: 2004-01-15 16:02:52|
|Subject: Weird query speed |
|Previous:||From: Matt Clark||Date: 2004-01-15 14:17:24|
|Subject: Re: insert speed - Mac OSX vs Redhat|