Re: Piggybacking vacuum I/O

On 1/24/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> 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