From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jignesh Shah <jkshah@gmail.com>
Cc: Ivan Voras <ivoras@freebsd.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance under contention
Date: Tue, 07 Dec 2010 12:50:43 -0500
Message-ID: <24822.1291744243@sss.pgh.pa.us> (raw)
In-Reply-To: <AANLkTimRPXTs0DXNLQT1nubeNT+tH2JHVXg1-KidvBcH@mail.gmail.com>
References: <icccng$kpg$1@dough.gmane.org>
<AANLkTinFqxaUnpq9E+oh6KcoyqPHDMxjS-_g3AJSPxmk@mail.gmail.com>
<AANLkTin7iSm3abU8cjWJYJZ4fDuz4Sg69rv17Xh5Z3J1@mail.gmail.com>
<AANLkTimRPXTs0DXNLQT1nubeNT+tH2JHVXg1-KidvBcH@mail.gmail.com>
Robert Haas <robertmhaas@gmail.com> writes:
> I wonder if it would be possible to have a very short critical section
> where we grab the partition lock, acquire the heavyweight lock, and
> release the partition lock; and then only as a second step record (in
> the form of a PROCLOCK) the fact that we got it.
[ confused... ] Exactly what do you suppose "acquire the lock" would
be represented as, if not "create a PROCLOCK entry attached to it"?
In any case, I think this is another example of not understanding where
the costs really are. As far as I can tell, on modern MP systems much
of the elapsed time in these operations comes from acquiring exclusive
access to shared-memory cache lines. Reducing the number of changes you
have to make within a small area of shared memory won't save much, once
you've paid for the first one. Changing structures that aren't heavily
contended (such as a proc's list of its own locks) doesn't cost much at
all.
One thing that might be interesting, but that I don't know how to attack
in a reasonably machine-independent way, is to try to ensure that shared
and local data structures don't accidentally overlap within cache lines.
When they do, you pay for fighting the cache line away from another
processor even when there's no real need.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, jkshah@gmail.com, ivoras@freebsd.org
Subject: Re: Performance under contention
In-Reply-To: <24822.1291744243@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox