From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Peter Bauer" <peter(dot)m(dot)bauer(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Major Performance decrease after some hours |
Date: | 2006-10-05 14:11:04 |
Message-ID: | 12772.1160057464@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Peter Bauer" <peter(dot)m(dot)bauer(at)gmail(dot)com> writes:
> tps = 50.703609 (including connections establishing)
> tps = 50.709265 (excluding connections establishing)
That's about what you ought to expect for a single transaction stream
running on honest disk hardware (ie, disks that don't lie about write
complete). You can't commit a transaction more often than once per disk
revolution, because you have to wait for the current WAL file endpoint
to pass under the heads again. If there are multiple clients then
"ganging" concurrent commits is possible, but you tested only one.
The benchmark you reference might have been done on disks with battery
backed write cache. Or it might have been just plain unsafe (ie, the
equivalent of fsync off, but in hardware :-()
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2006-10-05 14:18:51 | Re: Storing images in PostgreSQL databases (again) |
Previous Message | Peter Bauer | 2006-10-05 14:10:26 | Re: Major Performance decrease after some hours |