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

Re: Storing hot members of PGPROC out of the band

From: Jim Nasby <jim(at)nasby(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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 06:00:30
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Dec 16, 2011, at 7:25 PM, Bruce Momjian 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.

I also wonder how much this throws some previous performance tests into suspicion. If it's not uncommon for performance improvement attempts to shift a bottleneck to a different part of the system and marginally hurt performance then we might be throwing away good performance improvement ideas before we should...
Jim C. Nasby, Database Architect                   jim(at)nasby(dot)net
512.569.9461 (cell)               

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-12-17 07:25:35
Subject: Re: WIP: SP-GiST, Space-Partitioned GiST
Previous:From: Robert HaasDate: 2011-12-17 03:22:17
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe

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