Horton

Re: pg_stat_statements and "IN" conditions

Sami Imseih <samimseih@gmail.com>

View thread
From: Sami Imseih <samimseih@gmail.com>
To: Álvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Julien Rouhaud <rjuju123@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>, Sergei Kornilov <sk@zsrv.org>, yasuo.honda@gmail.com, tgl@sss.pgh.pa.us, smithpb2250@gmail.com, vignesh21@gmail.com, michael@paquier.xyz, nathandbossart@gmail.com, stark.cfm@gmail.com, geidav.pg@gmail.com, marcos@f10.com.br, robertmhaas@gmail.com, david@pgmasters.net, pgsql-hackers@postgresql.org, pavel.trukhanov@gmail.com, Sutou Kouhei <kou@clear-code.com>
Date: 2025-03-03T17:25:53Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Introduce squashing of constant lists in query jumbling

  2. Make documentation builds reproducible

  3. Include values of A_Const nodes in query jumbling

  4. Teach planner about more monotonic window functions

  5. Split up guc.c for better build speed and ease of maintenance.

Attachments

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

I don't have an example of non-immutable functions that should be folded,
but I also don't think query jumbling should care about the
function's volatility at all.

When dealing with FuncExpr, Why can't we simply skip merging when
func->funcformat != COERCE_IMPLICIT_CALL and the arguments
to the function are not constants? Meaning that anytime we have either
explicit casts or explicit function calls, this makes the list not eligible
for merging. See the attached .txt file to demonstrate what I am thinking.
This attached passes all the v28 test cases, but we will need to add tests
for implicit casts and external parameters.

-- 

Sami