Re: clog_buffers to 64 in 8.3? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: clog_buffers to 64 in 8.3?
Date
Msg-id 12784.1186073400@sss.pgh.pa.us
Whole thread Raw
In response to Re: clog_buffers to 64 in 8.3?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: clog_buffers to 64 in 8.3?  (Greg Smith <gsmith@gregsmith.com>)
Re: clog_buffers to 64 in 8.3?  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> Tom,
>> I don't actually think that what Jignesh is testing is a particularly
>> realistic scenario, and so I object to making performance decisions on
>> the strength of that one measurement.

> What do you mean by "not realistic"?  What would be a realistic scenario?

The difference between maxing out at 1200 sessions and 1300 sessions
doesn't excite me a lot --- in most environments you'd be well advised
to use many fewer backends and a connection pooler.  But in any case
the main point is that this is *one* benchmark on *one* platform.  Does
anyone outside Sun even know what the benchmark is, beyond the fact that
it's running a whole lot of sessions?

Also, you should not imagine that boosting NUM_CLOG_BUFFERS has zero
cost.  The linear searches used in slru.c start to look pretty
questionable if we want more than a couple dozen buffers.  I find it
entirely likely that simply changing the constant would be a net loss
on many workloads.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: clog_buffers to 64 in 8.3?
Next
From: Bruce Momjian
Date:
Subject: Re: GIT patch