On Thu, 2007-08-02 at 12:50 -0400, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> 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?

I like Greg Smith's idea to add a parameter, at least for testing.


> 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.

Doesn't that just beg the question: why do we have linear searches in
slru? The majority of access is going to be to the first 1-3 pages, so
adding an array that keeps track of the LRU would be much faster anyhow.
We can still scan the whole LRU before doing an I/O. That way we would
be able to vary the size of the caches.

  Simon Riggs
  EnterpriseDB  http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to