Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance - Mailing list pgsql-performance

From Robert Haas
Subject Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
Date
Msg-id AANLkTikKaNhHHimcO1XPdwvTCa-HYH4UJAGwgHjTKaQM@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-performance
On Thu, Oct 7, 2010 at 1:21 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>
>> perhaps it would be possible by, say, increasing the number of
>> lock partitions by 8x.  It would be nice to segregate these issues
>> though, because using pread/pwrite is probably a lot less work
>> than rewriting our lock manager.
>
> You mean easier than changing this 4 to a 7?:
>
> #define LOG2_NUM_LOCK_PARTITIONS  4
>
> Or am I missing something?

Right.  They did something more complicated (and, I think, better)
than that, but that change by itself might be enough to ameliorate the
lock contention enough to see the lsek() issue.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

pgsql-performance by date:

Previous
From: Aaron Turner
Date:
Subject: Re: large dataset with write vs read clients
Next
From: Robert Haas
Date:
Subject: Re: Odd behaviour with redundant CREATE statement