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