From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: clog_buffers to 64 in 8.3? |
Date: | 2007-08-02 16:50:00 |
Message-ID: | 12784.1186073400@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-08-02 17:34:40 | Re: GIT patch |
Previous Message | Josh Berkus | 2007-08-02 16:35:28 | Re: clog_buffers to 64 in 8.3? |