On Wed, Jan 25, 2012 at 12:00 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Tue, Jan 24, 2012 at 12:53 PM, Robert Haas <robertmh...@gmail.com> wrote: >> Early yesterday morning, I was able to use Nate Boley's test machine >> do a single 30-minute pgbench run at scale factor 300 using a variety >> of trees built with various patches, and with the -l option added to >> track latency on a per-transaction basis. All tests were done using >> 32 clients and permanent tables. The configuration was otherwise >> identical to that described here: >> >> http://archives.postgresql.org/message-id/CA+TgmoboYJurJEOB22Wp9RECMSEYGNyHDVFv5yisvERqFw=6...@mail.gmail.com > > Previously we mostly used this machine for CPU benchmarking. Have you > previously described the IO subsystem? That is becoming relevant for > these types of benchmarks. For example, is WAL separated from data?
I actually don't know much about the I/O subsystem, but, no, WAL is not separated from data. I believe $PGDATA is on a SAN, but I don't know anything about its characteristics. >> By doing this, I hoped to get a better understanding of (1) the >> effects of a scale factor too large to fit in shared_buffers, > > In my hands, the active part of data at scale of 300 fits very > comfortably into 8GB shared_buffers. > > Indeed, until you have run a very long time so that pgbench_history > gets large, everything fits in 8GB. Hmm, my mistake. Maybe I need to crank up the scale factor some more. This is why good benchmarking is hard. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
