Subject: Re: pg_stat_statements and "IN" conditions

From: vignesh C <[email-masked]>
Date: Mon, 17 Mar 2025 12:07:44 +0530

On Mon, 3 Mar 2025 at 17:26, Álvaro Herrera <[email-masked]> wrote:
>
> On 2025-Feb-18, Sami Imseih wrote:
>
> > > It's not a question about whether it's possible to implement this,
> > > but about whether it makes sense. In case of plain constants it's
> > > straightforward -- they will not change anything meaningfully and
> > > hence could be squashed from the query. Now for a function, that
> > > might return different values for the same set of constant
> > > arguments, it's much less obvious and omitting such expressions
> > > might have unexpected consequences.
> >
> > query jumbling should not care about the behavior of the function. If
> > we take a regular call to a volatile function, we will generate the
> > same queryId for every call regardless of the input to the function.
> > Why does the in-list case need to care about the volatility of the
> > function?
>
> I feel quite insecure about this idea TBH.  At least with immutable
> functions I don't expect the system to behave wildly different than with
> actual constants.  What non-immutable functions do you have in mind that
> would be useful to fold as if they were constants in the IN list in such
> a query?
>
> In the meantime, here's v28 which is Dmitry's v27 plus pgindent.  No
> other changes.  Dmitry, were you planning to submit a new version?

I noticed that the feedback from Sami at [1] has not yet been
addressed, I have changed the status to Waiting on Author, kindly
address them and update the status to Needs review.
[1] - https://www.postgresql.org/message-id/CAA5RZ0vt29Om%2BtKFOcUNhXV%2BkKpNnj0yj6OFho3-wngcMHWnAQ%40mail.gmail.com

Regards,
Vignesh

---

From: Dmitry Dolgov <[email-masked]>
Date: Mon, 17 Mar 2025 09:11:58 +0100

> On Mon, Mar 17, 2025 at 12:07:44PM GMT, vignesh C wrote:
>

I'm afraid there is a disagreement about this part of the feedback. I'm
not yet convinced about the idea suggested over there (treating mutable
functions in the same way as constants) and not planning to change
anything, at least not in the current version of the patch.

---

From: vignesh C <[email-masked]>
Date: Mon, 17 Mar 2025 13:58:33 +0530

> anything, at least not in the current version of the patch.

@Sami Imseih Do you have any other suggestions to solve this?
Others: Any thoughts on which way is better in this case?

Regards,
Vignesh

---

From: Álvaro Herrera <[email-masked]>
Date: Mon, 17 Mar 2025 09:44:20 +0100

> anything, at least not in the current version of the patch.

I have to admit that I am leaning towards removing the immutability
constraint.  The reason is that we already require the function to be
boostrapped (due to the OID test) and to have implicit cast form, so
that limits which functions are recognized; the only ones there that are
not immutable are:

         castsource          │        casttarget        │                 castfunc                 
─────────────────────────────┼──────────────────────────┼──────────────────────────────────────────
 text                        │ regclass                 │ regclass(text)
 character varying           │ regclass                 │ regclass(text)
 date                        │ timestamp with time zone │ timestamptz(date)
 time without time zone      │ time with time zone      │ timetz(time without time zone)
 timestamp without time zone │ timestamp with time zone │ timestamptz(timestamp without time zone)

Looking at this list, it seems rather random to me to say that we should
not squash arrays with types using these casts.  Should we really
consider two queries to be different because they run with different
search_path or TimeZone settings?

But kindly do not submit a new version of the patch, as I already have
some changes of my own (mostly on removing the term "merge" from code
and comments to replace with "squash", as well as adding some more
comments).  I'll post it soon.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/