Re: query_id: jumble names of temp tables for better pg_stat_statement UX
От | Sami Imseih |
---|---|
Тема | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |
Дата | |
Msg-id | CAA5RZ0u7cV1gi_JSXKQ_yJD6FHBT3o9jrkp1rTgtcM-HPQJW8w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: query_id: jumble names of temp tables for better pg_stat_statement UX (Lukas Fittl <lukas@fittl.com>) |
Список | pgsql-hackers |
> In my experience these often not work well with pg_stat_statements today because > of their own bloat problem, just like with temp tables. You quickly have way too many > unique entries, and your query text file accumulates a lot of duplicative entries > (since the same query text gets repeated in the text file, since its queryid is different), > to the point that you can't monitor your workload at all anymore. That is true in terms of pg_stat_statements, and I have seen users have to increase pg_stat_statements.max to something much higher to avoid the bloat and constant deallocs/GC. But, besides pg_stat_statements, queryId is used to group queries for database load monitoring ( pg_stat_activity sampling). As of now, different schemas are tracked separately, but with this change they will be merged. This may come as a surprise to use-cases that rely on the existing behavior. But I do agree that pg_s_s bloat is a big pain point, so this change should be positive overall. Let's see if there are enough complaints to force us to reconsider. -- Sami Imseih Amazon Web Services (AwS)
В списке pgsql-hackers по дате отправления: