Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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
