Re: pg_stat_statements and "IN" conditions - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: pg_stat_statements and "IN" conditions
Date
Msg-id 20231013133519.yf26oncodrvemfjw@ddolgov.remote.csb
Whole thread Raw
In response to Re: pg_stat_statements and "IN" conditions  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_stat_statements and "IN" conditions
List pgsql-hackers
> On Fri, Oct 13, 2023 at 05:07:00PM +0900, Michael Paquier wrote:
> Now, it doesn't mean that this approach with the "powers" will never
> happen, but based on the set of opinions I am gathering on this thread
> I would suggest to rework the patch as follows:
> - First implement an on/off switch that reduces the lists in IN and/or
> ANY to one parameter.  Simply.
> - Second, refactor the powers routine.
> - Third, extend the on/off switch, or just implement a threshold with
> a second switch.

Well, if it will help move this patch forward, why not. To clarify, I'm
going to split the current implementation into three patches, one for
each point you've mentioned.

> When it comes to my opinion, I am not seeing any objections to the
> feature as a whole, and I'm OK with the first step.  I'm also OK to
> keep the door open for more improvements in controlling how these
> IN/ANY lists show up, but there could be more than just the number of
> items as parameter (say the query size, different behaviors depending
> on the number of clauses in queries, subquery context or CTEs/WITH,
> etc. just to name a few things coming in mind).

Interesting point, but now it's my turn to have troubles imagining the
case, where list representation could be controlled depending on
something else than the number of elements in it. Do you have any
specific example in mind?



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [RFC] Add jit deform_counter
Next
From: David Steele
Date:
Subject: Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"