Re: Generating code for query jumbling through gen_node_support.pl
От | Michael Paquier |
---|---|
Тема | Re: Generating code for query jumbling through gen_node_support.pl |
Дата | |
Msg-id | Y9+HuYslMAP6yyPb@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Generating code for query jumbling through gen_node_support.pl (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Generating code for query jumbling through gen_node_support.pl
|
Список | pgsql-hackers |
On Tue, Jan 31, 2023 at 03:40:56PM +0900, Michael Paquier wrote: > With all that in mind, I have spent my day polishing that and doing a > close lookup, and the patch has been applied. Thanks a lot! While working on a different patch, I have noticed a small issue in the way the jumbling happens for A_Const, where ValUnion was not getting jumbled correctly. This caused a few statements that rely on this node to compile the same query IDs when using different values. The full contents of pg_stat_statements for a regression database point to: - SET. - COPY with queries. - CREATE TABLE with partition bounds and default expressions. This was causing some confusion in pg_stat_statements where some utility queries would be incorrectly reported, and at this point the intention is to keep this area compatible with the string-based method when it comes to the values. Like read, write and copy nodes, we need to compile the query ID based on the type of the value, which cannot be automated. Attached is a patch to fix this issue with some regression tests, that I'd like to get fixed before moving on with more business in pg_stat_statements (aka properly show Const nodes for utilities with normalized queries). Comments or objections are welcome, of course. (FWIW, I'd like to think that there is an argument to normalize the A_Const nodes for a portion of the DDL queries, by ignoring their values in the query jumbling and mark a location, which would be really useful for some workloads, but that's a separate discussion I am keeping for later.) -- Michael
Вложения
В списке pgsql-hackers по дате отправления: