Re: Scaling shared buffer eviction - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Scaling shared buffer eviction
Date
Msg-id CA+TgmoYOkGZjqNTOyH27H0DxJnfYORCbfyYFcwh9b9sbRCowYw@mail.gmail.com
Whole thread Raw
In response to Re: Scaling shared buffer eviction  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Scaling shared buffer eviction  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Scaling shared buffer eviction  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Fri, May 16, 2014 at 10:51 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:


Thrds (64)Thrds (128)
HEAD4556217128
HEAD + 645790432810
V1 + 6410555781011
HEAD + 1285838332997
V1 + 128110705114544

I haven't actually reviewed the code, but this sort of thing seems like good evidence that we need your patch, or something like it.  The fact that the patch produces little performance improvement on it's own (though it does produce some) shouldn't be held against it - the fact that the contention shifts elsewhere when the first bottleneck is removed is not your patch's fault.

In terms of ameliorating contention on the buffer mapping locks, I think it would be better to replace the whole buffer mapping table with something different.  I started working on that almost 2 years ago, building a hash-table that can be read without requiring any locks and written with, well, less locking than what we have right now:

http://git.postgresql.org/gitweb/?p=users/rhaas/postgres.git;a=shortlog;h=refs/heads/chash

I never got quite as far as trying to hook that up to the buffer mapping machinery, but maybe that would be worth doing.

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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: CREATE REPLICATION SLOT fails on a timeout
Next
From: Peter Geoghegan
Date:
Subject: Re: Scaling shared buffer eviction