Re: queryId constant squashing does not support prepared statements

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: queryId constant squashing does not support prepared statements
Date: 2025-05-24 01:05:47
Message-ID: CAA5RZ0v16yTMi5dKv2dQUwRhpG1OiZSgmr0=2dS81gyp9iDEew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-05-24 01:10:23 Fixing memory leaks in postgres_fdw
Previous Message Michael Paquier 2025-05-24 00:47:21 Re: mention unused_oids script in pg_proc.dat