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

From Alvaro Herrera
Subject Re: pg_stat_statements and "IN" conditions
Date
Msg-id 20230209172651.cfgrebpyyr72h7fv@alvherre.pgsql
Whole thread Raw
In response to Re: pg_stat_statements and "IN" conditions  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: pg_stat_statements and "IN" conditions
List pgsql-hackers
On 2023-Feb-09, Dmitry Dolgov wrote:

> > On Thu, Feb 09, 2023 at 02:30:34PM +0100, Peter Eisentraut wrote:

> > What is the point of making this a numeric setting?  Either you want
> > to merge all values or you don't want to merge any values.
> 
> At least in theory the definition of "too many constants" is different
> for different use cases and I see allowing to configure it as a way of
> reducing the level of surprise here.

I was thinking about this a few days ago and I agree that we don't
necessarily want to make it just a boolean thing; we may want to make it
more complex.  One trivial idea is to make it group entries in powers of
10: for 0-9 elements, you get one entry, and 10-99 you get a different
one, and so on:

# group everything in a single bucket
const_merge_threshold = true / yes / on 

# group 0-9, 10-99, 100-999, 1000-9999
const_merge_treshold = powers

Ideally the value would be represented somehow in the query text. For
example

                         query                            | calls
----------------------------------------------------------+-------
 select * from test where i in ({... 0-9 entries ...})    |     2
 select * from test where i in ({... 10-99 entries ...})  |     1

What do you think?  The jumble would have to know how to reduce all
values within each power-of-ten group to one specific value, but I don't
think that should be particularly difficult.


-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Find a bug in a program, and fix it, and the program will work today.
Show the program how to find and fix a bug, and the program
will work forever" (Oliver Silfridge)



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: recovery modules
Next
From: Andres Freund
Date:
Subject: Re: MacOS: xsltproc fails with "warning: failed to load external entity"