From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Staubo <alex(at)purefiction(dot)net> |
Cc: | Michael Stone <mstone+postgres(at)mathom(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: New to PostgreSQL, performance considerations |
Date: | 2006-12-12 15:47:42 |
Message-ID: | 3356.1165938462@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Alexander Staubo <alex(at)purefiction(dot)net> writes:
> No, fsync=on. The tps values are similarly unstable with fsync=off,
> though -- I'm seeing bursts of high tps values followed by low-tps
> valleys, a kind of staccato flow indicative of a write caching being
> filled up and flushed.
It's notoriously hard to get repeatable numbers out of pgbench :-(
A couple of tips:
* don't put any faith in short runs. I usually use -t 1000
plus -c whatever.
* make sure you loaded the database (pgbench -i) with a scale
factor (-s) at least equal to the maximum -c you want to test.
Otherwise you're mostly measuring update contention.
* pay attention to when checkpoints occur. You probably need
to increase checkpoint_segments if you want pgbench not to be
checkpoint-bound.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel van Ham Colchete | 2006-12-12 15:57:20 | Re: New to PostgreSQL, performance considerations |
Previous Message | Bill Moran | 2006-12-12 15:26:10 | Re: New to PostgreSQL, performance considerations |