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

Re: Avoiding repeated snapshot computation

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: andres(at)anarazel(dot)de, singh(dot)gurjeet(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 04:51:40
Message-ID: CABOikdNUupQpLLv7BY4152ehi8ynS2SXvg__uLoROZXH4+DzDA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Nov 29, 2011 at 8:30 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> 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 think there is fundamental difference between the PGPROC patch that
we did and the rearranging SnapshotData members that Andres has
proposed. The PGPROC structure is a shared memory area, very heavily
accessed by GetSnapshotData (and some others). There was a linear
increase in the access as number of clients go up. The SnapshotData
structure is mostly from a backend local memory (unless we do
something what I suggested in the OP) and hence fitting that in a
single cache line may or may not have much impact. We don't even
guarantee that it starts at a cacheline which means in most cases it
will still be spread on multiple cache lines.

Thanks,
Pavan
-- 
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-11-29 05:01:41
Subject: Re: plpython SPI cursors
Previous:From: Pavel StehuleDate: 2011-11-29 04:50:33
Subject: Re: psql editor temp file extension

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