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

Re: Avoiding repeated snapshot computation

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <andres(at)anarazel(dot)de>,<singh(dot)gurjeet(at)gmail(dot)com>
Cc: <pavan(dot)deolasee(at)gmail(dot)com>,<robertmhaas(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Avoiding repeated snapshot computation
Date: 2011-11-29 03:00:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andres Freund  wrote:
> I would like to see somebody running a benchmark on a machine with
> higher concurrency...
Yeah, me too.  I don't find it at all hard to believe that we will
see significant performance benefit by changing the PGPROC structure
so that all parts of it can be accessed through one cache line rather
than two.  The fact that we saw improvement when changing it down to
two, even though there is extra indirection in some places, seems
like pretty solid evidence on the face of it.
I went in to the office on Sunday to try to get a few hours of
benchmarks for this on our new monster machine, but the DBA
responsible for putting it into production was on it first, loading
it with production data.  At this point it will get really hard to
schedule any more of the 20-hour runs that were the basis of most of
my recent numbers, but I may be able to shut down production use for
a two or three hour window on a weekend to run an abbreviated set,
focusing on the higher concurrency levels.  Ideally that would be on
top of the other pending performance patches.
Based on my earlier rounds of benchmarking, I expect that this
approach will show the greatest benefit at the higher concurrency
levels, where cache lines are most stressed.


pgsql-hackers by date

Next:From: Nathan BoleyDate: 2011-11-29 03:02:51
Subject: Re: WIP: collect frequency statistics for arrays
Previous:From: Bruce MomjianDate: 2011-11-29 02:58:32
Subject: Re: perltidy

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