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

pg_lock_status() performance

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: pg_lock_status() performance
Date: 2009-04-28 17:53:45
Message-ID: b42b73150904281053r6b4823berba0183dcd33ec7ef@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
I have a unloaded development server running 8.4b1 that is returning
from a 'select * from pg_locks' in around 5 ms.  While the time itself
is not a big deal, I was curious and tested querying locks on a fairly
busy (200-500 tps sustained)  running 8.2 on inferior hardware.  This
returned (after an initial slower time) in well under 1 ms most of the
time.  Is this noteworthy?  What factors slow down best case
pg_lock_status() performance?

edit: I bet it's the max_locks_per_transaction parameter. I really
cranked it on the dev box during an experiment, to 16384.
testing...yup that's it.  Are there any negative performance
side-effects that could result from (perhaps overly) cranked
max_locks_per_transaction?

merlin

Responses

pgsql-performance by date

Next:From: Scott MarloweDate: 2009-04-28 17:56:25
Subject: Re: partition question for new server setup
Previous:From: Whit ArmstrongDate: 2009-04-28 17:48:40
Subject: Re: partition question for new server setup

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