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
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 |