Re: queryId constant squashing does not support prepared statements
От | Dmitry Dolgov |
---|---|
Тема | Re: queryId constant squashing does not support prepared statements |
Дата | |
Msg-id | j2ebrpvxpglwkpead4efsl77jp3csywzdfsn5s2aarvrd5yhbx@hrmxlqjavh62 обсуждение исходный текст |
Ответ на | Re: queryId constant squashing does not support prepared statements (Dmitry Dolgov <9erthalion6@gmail.com>) |
Список | pgsql-hackers |
> On Fri, May 09, 2025 at 08:47:58AM GMT, Michael Paquier wrote: > SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C"; > - query | calls > -----------------------------------------------------+------- > - SELECT ARRAY[$1 /*, ... */] | 1 > - SELECT pg_stat_statements_reset() IS NOT NULL AS t | 1 > + query | calls > +-------------------------------------------------------+------- > + SELECT ARRAY[$1, $2, $3, $4, $5, $6, $7, $8, $9, $10] | 1 > + SELECT pg_stat_statements_reset() IS NOT NULL AS t | 1 > (2 rows) > > Yes, we are going to need more than that for such cases if we want to > cover all the ground we're aiming for. > > Putting that aside, the test coverage for ARRAY[] elements is also > very limited on HEAD with one single test only with a set of > constants. We really should improve that, tracking more patterns and > more mixed combinations to see what gets squashed and what is not. So > this should be extended with more cases, including expressions, > parameters and sublinks, with checks on pg_stat_statements.calls to > see how the counters are aggregated. That's going to be important > when people play with this code to track how things change when > manipulating the element jumbling. I'd suggest to do that separately > of the rest. Agree, I'll try to extend number of test cases here as a separate patch.
В списке pgsql-hackers по дате отправления: