pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Віталій Тимчишин <tivv00@gmail.com>
Cc: Ivan Voras <ivoras@freebsd.org>
Cc: Jignesh Shah <jkshah@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance under contention
Date: Wed, 08 Dec 2010 17:02:19 -0500
Message-ID: <21911.1291845739@sss.pgh.pa.us> (raw)
In-Reply-To: <AANLkTimzGPikGwz-G_bGn8kzFK2RyUxf9cDFQk7E8Zk1@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>
	<AANLkTim1EphkUMV=PWV0mF8HaGHqH2H+whnFtqPOnTN_@mail.gmail.com>
	<AANLkTi=q6EFaTuWU9gVFC3g8+6FucFguwBxcyauwEdjh@mail.gmail.com>
	<AANLkTinffMekisiwq9Dip9uWxG2_qeMgPkctw=nCkZmv@mail.gmail.com>
	<AANLkTim2nr+pKJ6ZwduEthzdV94=Ovh9ys_E6nEZCWbr@mail.gmail.com>
	<AANLkTin=vVgkpYe2u_WBVHV59dgbe5QZ6PZ-nsT28Yb5@mail.gmail.com>
	<14229.1291818863@sss.pgh.pa.us>
	<AANLkTimzGPikGwz-G_bGn8kzFK2RyUxf9cDFQk7E8Zk1@mail.gmail.com>

Robert Haas <robertmhaas@gmail.com> writes:
> 2010/12/8 Tom Lane <tgl@sss.pgh.pa.us>:
>> Now, it's possible that you could avoid *ever* needing to search for a
>> specific PROCLOCK, in which case eliminating the hash calculation
>> overhead might be worth it.

> That seems like it might be feasible.  The backend that holds the lock
> ought to be able to find out whether there's a PROCLOCK by looking at
> the LOCALLOCK table, and the LOCALLOCK has a pointer to the PROCLOCK.

Hm, that is a real good point.  Those shared memory data structures
predate the invention of the local lock tables, and I don't think we
looked real hard at whether we should rethink the fundamental
representation in shared memory given the additional local state.
The issue though is whether any other processes ever need to look
at a proc's PROCLOCKs.  I think at least deadlock detection does.

			regards, tom lane



view thread (34+ messages)  latest in thread

Message-ID: <21911.1291845739@sss.pgh.pa.us>
Permalink:  ../21911.1291845739@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/21911.1291845739@sss.pgh.pa.us

 · 

reply
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, tivv00@gmail.com, ivoras@freebsd.org, jkshah@gmail.com
  Subject: Re: Performance under contention
  In-Reply-To: <21911.1291845739@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