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: 4ED3F6610200002500043593@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

-Kevin

Responses

Browse pgsql-hackers by date

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