Re: queryId constant squashing does not support prepared statements
От | Sami Imseih |
---|---|
Тема | Re: queryId constant squashing does not support prepared statements |
Дата | |
Msg-id | CAA5RZ0umxGnL4un9_yBiwjjV26VY0wubt0Zoz5hcE3S2K5xXjg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: queryId constant squashing does not support prepared statements (Dmitry Dolgov <9erthalion6@gmail.com>) |
Список | pgsql-hackers |
> > On Thu, May 22, 2025 at 10:23:31PM GMT, Sami Imseih wrote: > > > This does not get squashed: > > > Q: select where 2 in (1, 4) and > > > 1 in (5, cast(7 as int), 6, (cast(8 as int)), 9, 10, (cast(8 as text))::int); > > > R: select where $1 in ($2 /*, ... */) and > > > $3 in ($4, cast($5 as int), $6, (cast($7 as int)), $8, $9, (cast($10 as text))::int) > > > > This is interesting actually. This is the behavior on HEAD, and I don't get why > > the first list with the casts does not get squashed, while the second one does. > > I will check IsSquashableConst tomorrow unless Dmitry gets to it first. > > IsSquashableConst has intentionally a limited set of test for > "constantness", in particular it does not recurse. The case above > > (cast(8 as text))::int > > features two CoerceViaIO expressions one inside another, hence > IsSquashableConst returns false. Should we be doing something like this? to unwrap RelabelType or CoerceViaIO until we have a different type of node to check for later on. We can guard the loop and break out after x amount of times as well. At minimum, we should try to unwrap at least 2 times for some of the common real-world scenarios. What do you think? ``` while (IsA(element, RelabelType) || IsA(element, CoerceViaIO)) { if (IsA(element, RelabelType)) element = (Node *) ((RelabelType *) element)->arg; else if (IsA(element, CoerceViaIO)) element = (Node *) ((CoerceViaIO *) element)->arg; } ``` -- Sami
В списке pgsql-hackers по дате отправления: