Re: pg_stat_statements and "IN" conditions

From: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, yasuo(dot)honda(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, smithpb2250(at)gmail(dot)com, michael(at)paquier(dot)xyz, nathandbossart(at)gmail(dot)com, stark(dot)cfm(at)gmail(dot)com, geidav(dot)pg(at)gmail(dot)com, marcos(at)f10(dot)com(dot)br, robertmhaas(at)gmail(dot)com, david(at)pgmasters(dot)net, pgsql-hackers(at)postgresql(dot)org, pavel(dot)trukhanov(at)gmail(dot)com, Sutou Kouhei <kou(at)clear-code(dot)com>
Subject: Re: pg_stat_statements and "IN" conditions
Date: 2025-03-17 08:44:20
Message-ID: 202503170844.j7tmqg22dq6o@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025-Mar-17, Dmitry Dolgov 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.

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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2025-03-17 08:47:33 Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning
Previous Message Zharkov Roman 2025-03-17 08:43:13 Re: plperl version on the meson setup summary screen