Re: Lock partitions

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

In response to

Responses

Browse pgsql-hackers by date

  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