Re: queryId constant squashing does not support prepared statements - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: queryId constant squashing does not support prepared statements
Date
Msg-id CAA5RZ0v16yTMi5dKv2dQUwRhpG1OiZSgmr0=2dS81gyp9iDEew@mail.gmail.com
Whole thread Raw
In response to Re: queryId constant squashing does not support prepared statements  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: queryId constant squashing does not support prepared statements
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Retiring some encodings?
Next
From: Tom Lane
Date:
Subject: Fixing memory leaks in postgres_fdw