From: | Mark Wong <markw(at)osdl(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Lock partitions |
Date: | 2006-10-18 15:47:19 |
Message-ID: | 45364C87.8000808@osdl.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan de Visser | 2006-10-18 15:49:27 | Re: 8.1.5 is out |
Previous Message | Jie Zhang | 2006-10-18 15:38:45 | Re: Bitmap index status |