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 | CAM3SWZTbB96TJwSWcs=aeDCGDGwrgTSqRnPA2OqTvyvba36ZNg@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
|
Список | pgsql-hackers |
On Sat, Jan 25, 2014 at 1:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I've chosen to handle failures to load query > text data by just returning NULL for that query text, which seems > reasonable given the new mindset that the query text is auxiliary data > less important than the actual counts. I guess that's okay. > I've not done much more than smoke-testing on this; I'm thinking about > hot-wiring the code to sometimes force it through the error paths, > just to make sure they act as expected. I've also not done any > real performance testing. I was never too worried about the impact on performance, because any price that must be paid is paid only when new entries are created, which is typically a very rare event that was already expensive due to requiring an exclusive lock. This patch will make it much rarer in practice by increasing the pg_stat_statements.max default, and thus reducing the impact on such exclusive locks on *all* sessions, not just those executing less popular queries. I don't know about you, but the reason that I didn't performance test this is that it's really hard to think of a representative scenario where it could possibly matter, even though it seems like there might be one. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: