This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Greg Smith wrote:
On Thu, 2 Aug 2007, Tom Lane wrote:
I find it entirely likely that simply changing the
On Fri, 2007-08-03 at 18:16 -0400, Tom Lane wrote:
In any case this is getting pretty darn far away from a one-liner patch.
I think it needs more thought and more testing than we can spare now.
Agreed.
We're much further behind with this release than ever before, so we need
to put the cut
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
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2007-08-02 at 12:50 -0400, Tom Lane wrote:
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.
Doesn't that
Tom,
In any case this is getting pretty darn far away from a one-liner patch.
I think it needs more thought and more testing than we can spare now.
I'm still hoping that we can show that a moderate increase (say 24 or 32)
has no noticeable effect on other workloads. Haven't had time to run
Josh Berkus [EMAIL PROTECTED] writes:
Through the User Concurrency Thread on -performance [1], Tom and
Jignesh found that our proximate bottleneck on SMP multi-user scaling
is clog_buffers.
I don't actually think that what Jignesh is testing is a particularly
realistic scenario, and so I
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
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?
--
Josh Berkus
PostgreSQL @ Sun
San
On Thu, 2 Aug 2007, Tom Lane wrote:
I find it entirely likely that simply changing the [NUM_CLOG_BUFFERS]
constant would be a net loss on many workloads.
Would it be reasonable to consider changing it to a compile-time option
before the 8.3 beta? From how you describe the potential