Re: Sorted writes in checkpoint
Zeugswetter Andreas DCP SD <zeugswettera@spardat.at>
From: "Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>
To: "Simon Riggs" <simon@2ndquadrant.com>, "ITAGAKI Takahiro" <itagaki.takahiro@oss.ntt.co.jp>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>, "Greg Smith" <gsmith@gregsmith.com>, "Heikki Linnakangas" <heikki@enterprisedb.com>
Date: 2007-06-15T09:14:20Z
Lists: pgsql-hackers
> > tests | pgbench | DBT-2 response time > (avg/90%/max) > > > ---------------------------+---------+-------------------------------- > > ---------------------------+---------+--- > > LDC only | 181 tps | 1.12 / 4.38 / 12.13 s > > + BM_CHECKPOINT_NEEDED(*) | 187 tps | 0.83 / 2.68 / 9.26 s > > + Sorted writes | 224 tps | 0.36 / 0.80 / 8.11 s > > > > (*) Don't write buffers that were dirtied after starting > the checkpoint. > > > > machine : 2GB-ram, SCSI*4 RAID-5 > > pgbench : -s400 -t40000 -c10 (about 5GB of database) > > DBT-2 : 60WH (about 6GB of database) > > I'm very surprised by the BM_CHECKPOINT_NEEDED results. What > percentage of writes has been saved by doing that? We would > expect a small percentage of blocks only and so that > shouldn't make a significant difference. I thought we Wouldn't pages that are dirtied during the checkpoint also usually be rather hot ? Thus if we lock one of those for writing, the chances are high that a client needs to wait for the lock ? A write os call should usually be very fast, but when the IO gets bottlenecked it might easily become slower. Probably the recent result, that it saves ~53% of the writes, is sufficient explanation though. Very nice results :-) Looks like we want all of it including the sort. Andreas