Re: queryId constant squashing does not support prepared statements
От | Sami Imseih |
---|---|
Тема | Re: queryId constant squashing does not support prepared statements |
Дата | |
Msg-id | CAA5RZ0v16yTMi5dKv2dQUwRhpG1OiZSgmr0=2dS81gyp9iDEew@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: queryId constant squashing does not support prepared statements (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: queryId constant squashing does not support prepared statements
|
Список | pgsql-hackers |
> On Fri, May 23, 2025 at 04:29:45PM +0200, Dmitry Dolgov wrote: > > I think it's better to recursively call IsSquashableConst on the nested > > expression (arg or args for FuncExpr). Something like that was done in > > the original patch version and was concidered too much at that time, but > > since it looks like all the past concerns are lifted, why not. Do not > > forget check_stack_depth. > > AFAIK, we have already a couple of check_stack_depth() calls during > some node transformations after-parsing. At this level of the code > that would be a new thing.. I think the recursion will simplify the logic inside IsSquashableConstants. I will probably add that as a separate patch that maybe will get applied to HEAD only. Something I want agreement on is the following. Since we assign new parameter symbols based on the highest external param from the original query, as stated in the docs [0] "The parameter symbols used to replace constants in representative query texts start from the next number after the highest $n parameter in the original query text", we could have gaps in assigning symbol values, such as the case below. ``` test=# select where 1 in ($1, $2, $3) and 1 = $4 test-# \bind 1 2 3 4 test-# ; -- (0 rows) test=# select query from pg_stat_statements; query ------------------------------------------------ select where $5 in ($6 /*, ... */) and $7 = $4 ``` I don't think there is much we can do here, without introducing some serious complexity. I think the docs make this scenario clear. Thoughts? [0] https://www.postgresql.org/docs/current/pgstatstatements.html -- Sami
В списке pgsql-hackers по дате отправления: