From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Sami Imseih <samimseih(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, vignesh21(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-18 09:45:14 |
Message-ID: | ityjgjeekboyjwpzkbtqyrcopi7hdrh4blwcux6rft7sux3qj5@tufruueqvorn |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Mon, Mar 17, 2025 at 08:14:16PM GMT, Álvaro Herrera wrote:
> On 2025-Mar-17, Álvaro Herrera wrote:
>
> > You can see my patch on top of yours here:
> > https://github.com/alvherre/postgres/commits/query_id_squash_values/
> > and the CI run here:
> > https://cirrus-ci.com/build/5660053472018432
>
> Heh, this blew up on bogus SGML markup :-( Fixed and running again:
> https://cirrus-ci.com/build/4822893680394240
Thanks, much appreciated! I've inspected the diff between patches and run few
tests, at the first glance everything looks fine.
> I am tempted to say that explicit casts should also be considered
> squashable (that is, in IsSquashableConst() also allow the case of
> func->funcformat == COERCE_EXPLICIT_CAST).
Well, I admit I may have been burned too much by the initial reception of the
patch and handled it too conservatively in this regard. Originally I also had a
concern about normalized queries representation for explicit cast case, but it
was resolved by Julien's suggestion to switch to the /* ... */ format.
> 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)
Agree, when put together with the OID limitation it doesn't look so bad.
Somehow I was thinking about the Sami's proposal and the discussion in more
abstract terms, as if we talk about any arbitrary mutable functions to squash
-- I still would be cautious about hiding non-bootstrapped mutable functions.
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2025-03-18 09:45:41 | Re: ecdh support causes unnecessary roundtrips |
Previous Message | Daniel Verite | 2025-03-18 09:36:28 | Re: Add Pipelining support in psql |