Skip site navigation (1) Skip section navigation (2)

Re: Storing hot members of PGPROC out of the band

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Storing hot members of PGPROC out of the band
Date: 2011-12-17 02:54:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Dec 16, 2011 at 8:25 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> On that theory, I'm inclined to think that's not really a problem.
>> We'll go nuts if we refuse to commit anything until it shows a
>> meaningful win on every imaginable workload, and it seems like this
>> can't really be worse than the status quo; any case where it is must
>> be some kind of artifact.  We're better of getting rid of as much
>> ProcArrayLock contention as possible, rather than keeping it around
>> because there are corner cases where it decreases contention on some
>> other lock.
> Interesting conclusion, and it makes sense.  Seems once this is applied
> we will have more places to look for contention improvements.

Yeah.  The performance results I posted the other day seem to show
that on some of these tests we're thrashing our CLOG buffers, and the
difference between unlogged tables and permanent tables seems to
indicate pretty clearly that WALInsertLock is a huge problem.  I'm
going to look more at the CLOG stuff next week, and also keep poking
at ProcArrayLock, where I think there's still room for further
improvement.  I am leaving WALInsertLock to Heikki for now, since (1)
I don't want to collide with what he's working on, (2) he knows more
about it than I do, anyway, and (3) it's a really hard problem and I
don't have any particularly good ideas about how to fix it.  :-(

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-12-17 03:22:17
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Previous:From: Robert HaasDate: 2011-12-17 02:26:31
Subject: Re: JSON for PG 9.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group