Re: pg_lock_status() performance

From: Tom Lane
Subject: Re: pg_lock_status() performance
Date: ,
Msg-id: 18461.1240954881@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: pg_lock_status() performance  (Merlin Moncure)
Responses: Re: pg_lock_status() performance  (Merlin Moncure)
List: pgsql-performance

Tree view

pg_lock_status() performance  (Merlin Moncure, )
 Re: pg_lock_status() performance  (Tom Lane, )
  Re: pg_lock_status() performance  (Merlin Moncure, )
   Re: pg_lock_status() performance  (Merlin Moncure, )
    Re: pg_lock_status() performance  (Tom Lane, )

Merlin Moncure <> writes:
> 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?

[squint...]  AFAICS the only *direct* cost component in pg_lock_status
is the number of locks actually held or awaited.  If there's a
noticeable component that depends on max_locks_per_transaction, it must
be from hash_seq_search() iterating over empty hash buckets.  Which is
a mighty tight loop.  What did you have max_connections set to?

            regards, tom lane


pgsql-performance by date:

From: Scott Carey
Date:
Subject: Re: partition question for new server setup
From: Scott Carey
Date:
Subject: Re: partition question for new server setup