Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
Date
Msg-id CAM3SWZS0yB4SdWqJz2NZTUYUKNCJA0KNR6Hu+nRCdn=FWEaVNg@mail.gmail.com
Whole thread Raw
In response to Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jan 25, 2014 at 2:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, it's fairly expensive to generate that text, in the case of a
> large/complex statement.  It's possible that continuing to hold the lock
> is nonetheless the right thing to do because release+reacquire is also
> expensive; but there is no proof of that AFAIK, and I believe that
> release+reacquire is not likely to be expensive unless the lock is heavily
> contended, which would be exactly the conditions under which keeping it
> wouldn't be such a good idea anyway.

My reason for only acquiring the shared lock once, and performing text
normalization with it held was that in practice most query texts are
not all that expensive to lex/normalize, and the cost of holding the
lock for the vast majority of sessions (that won't experience
contention) is nil. Acquiring the shared lock twice for something like
that struck me as unjustified. I though it was closer to the original
coding to lex with the lock, because of course the original coding
will only ever acquire the shared lock once. The original
lex-with-no-lock coding is only justified by "well, might as well".

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Next
From: Andrew Dunstan
Date:
Subject: Re: Visual Studio 2013 build