Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I see this in the CVS commits for 8.2. Did we determine the proper
number of lock partitions? Should it be based on the number of buffers
or concurrent sessions allowed?
No. NUM_LOCK_PARTITIONS needs to be a compile-time constant for a
number of reasons, and there is absolutely zero evidence to justify
making any effort (and spending any cycles) on a variable value.
It would be nice to see some results from the OSDL tests with, say, 4,
8, and 16 lock partitions before we forget about the point though.
Anybody know whether OSDL is in a position to run tests for us?
I have a couple of bigger runs now against a CVS checkout on 2006-09-20
(please forgive my NUM_BUFFER_PARTITIONS note if you notice that on the
web pages):
Baseline (default NUM_LOCK_PARTITIONS=4):
notpm 6589
http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/184/
NUM_LOCK_PARTITIONS=8:
notpm 4471
http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/180/
NUM_LOCK_PARTITIONS=16:
Failed to run.
The number of transaction errors increased when I increased the
NUM_LOCK_PARTITIONS, which I think is the reason it failed to run when I
set it to 16. And the throughput went down significantly (32%). Should
I try against a more recent checkout?
Mark
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
