Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
Дата
Msg-id CAM3SWZS0yB4SdWqJz2NZTUYUKNCJA0KNR6Hu+nRCdn=FWEaVNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Visual Studio 2013 build