On 21 Aug 2003 at 8:22, expect wrote:
> On Thu, 21 Aug 2003 12:55:35 +0530
> Shridhar Daithankar <shridhar_daithankar@persistent.co.in> wrote:
> > > Both 7.3.4 and 7.4 had:
> > >
> > > 3072 buffers
> > > 4096K sort memory
> > > 16384K vacuum memory
> >
> > Since you weren't running any huge sorts thr. pgbench and vacuum, canyou drop
> > last two to half of these and check?
> Just trying to learn a little more about pg perf. behavior....
> Are you suggesting that with less memory to "manage" that pg
> will run more efficiently?
Yes. If that is not required, bumping them unnecessarily could have unwanted
side effects at times.
> > > fsync false
> > > 16 WAL buffers
> > > statistics on
> >
> > I would put more WAL buffers. 32-64 maybe..
>
> It would be interesting to see 10 or 20 plateaus for that number or
> at least up to the point of diminishing returns for the load that's applied.
> Or maybe it wouldn't? Maybe it scales.
WAL is where are transactions are channelled. Pgbench is heavy on transactions
I understand. So if you are trying to tight-loop pgbench for exceedingly large
number of transactions, WAL will be hit like anything and likely become
bottleneck.
If you have bit bigger WAL buffers, then the bottleneck would be slightly eases
but but still it will eb limited by disk IO bandwidth.
Having too many smalll transactions too rapidly can not deliver performance
unless you have proportionate disk bandwidth. You need to size them
appropriately if possible.
HTH
Bye
Shridhar
--
It is more rational to sacrifice one life than six. -- Spock, "The Galileo
Seven", stardate 2822.3
