Re: Correctly propagate queryId for utility stmt in function
| От | Michael Paquier |
|---|---|
| Тема | Re: Correctly propagate queryId for utility stmt in function |
| Дата | |
| Msg-id | Zpmvly3YGDH6OWGz@paquier.xyz обсуждение исходный текст |
| Ответ на | Correctly propagate queryId for utility stmt in function (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>) |
| Список | pgsql-hackers |
On Thu, Jul 18, 2024 at 01:37:40PM +0200, Anthonin Bonnefoy wrote: > For utility statements defined within a function, the queryTree is > copied to a plannedStmt as utility commands don't require planning. > However, the queryId is not propagated to the plannedStmt. This leads > to plugins relying on queryId like pg_stat_statements to not be able > to track utility statements within function calls. You are right, good catch. This leads to only partial information being reported depending on the setting of pg_stat_statements.track. It is a point of detail, but I'd rather expand a bit more the tests on top of what you are proposing: - Upper and down-casing for non-top utility commands, to check that they are counted consistently. - Check with pg_stat_statements.track = 'top' - Not cross-checking pg_stat_statements.track_utility = false is OK. While this qualifies as something that could go down to all the stable branches, it is much easier to think about utility statements in 16~ now that we compile the query IDs depending on their parsed tree, so will apply down to that. pg_stat_statements tests have also been refactored in 16~, but that's a nit here.. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: