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

From Tom Lane
Subject Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
Date
Msg-id 10426.1390688424@sss.pgh.pa.us
Whole thread Raw
In response to Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
> Why do you think it's better to release the shared lock while
> generating a normalized query text, only to acquire it once more? I'm
> not suggesting that it's the wrong thing to do. I'm curious about the
> reasoning around assessing the costs.

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.  So I'd prefer to leave it doing what
it did before, until there's some concrete evidence that keeping the lock
is a better idea.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: A minor correction in comment in heaptuple.c
Next
From: Andres Freund
Date:
Subject: Re: Changeset Extraction v7.1