On 1/24/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes: > On a typical desktop class 2 CPU Dell machine, we have seen pgbench > clocking more than 1500 tps. Only if you had fsync off, or equivalently a disk drive that lies about write-complete. You could possibly achieve such rates in a non-broken configuration with a battery-backed write cache, but that's not "typical desktop" kit.
May be I was too vague about the machine/test. Its probably not a "typical desktop" machine since it has better storage. A two disk RAID 0 configuration for data, and a dedicated disk for xlog. I remember running with 50 clients and 50 scaling factor, 1 GB shared buffer, autovacuum turned on with default parameters and rest with default configuration. I don't think I had explicitly turned fsync off.
In any case, you ignored Heikki's point that the PG shared memory pages holding CLOG are unlikely to be the sole level of caching, if the update rate is that high. The kernel will have some pages too. And even if we thought not, wouldn't bumping the size of the clog cache be a far simpler solution offering benefit for more things than just this?
Yes. May be what Heikki said is true, but we don't know for sure. Wouldn't bumping the cache size just delay the problem a bit ? Especially with even larger table and a very high end machine/storage which can clock very high transactions per minute ? Anyways, if we agree that there is a problem, the solution could be as simple as increasing the cache size, as you suggested. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com