Date: Thu, 10 Mar 2022 17:38:37 +0100
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Zhihong Yu <zyu@yugabyte.com>, David Steele <david@pgmasters.net>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Greg Stark <stark@mit.edu>,
	Pavel Trukhanov <pavel.trukhanov@gmail.com>
Subject: Re: pg_stat_statements and "IN" conditions
Message-ID: <20220310163837.pzvr4yntdk33cbkb@ddolgov.remote.csb>
References: <CALNJ-vRRrdXu9igzh5PFTBghK5hnQWF6gpntTPo_+Agq_TsT5Q@mail.gmail.com>
 <ec47aa60-0a7b-ea3a-222a-5c6a754c2def@pgmasters.net>
 <20210318155002.ggrgf2p2mvaodcox@localhost>
 <20210615151850.6nsue7z5xjhpytle@localhost>
 <20210616140212.kt3n5wi3alfz5i5d@localhost>
 <20210930134930.d4vzwhvxhfpk2zxt@localhost>
 <CALNJ-vSJvaJbcXr46JMyWFT5rO3BdaHO2E=xnAbLNDw1cyUJ-A@mail.gmail.com>
 <20210930150957.tz3h3unjyrzatw6e@localhost>
 <4154685.1641337363@sss.pgh.pa.us>
 <20220105211111.5oh7ypjfonaqubuq@erthalion.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220105211111.5oh7ypjfonaqubuq@erthalion.local>
Archived-At: <https://www.postgresql.org/message-id/20220310163837.pzvr4yntdk33cbkb%40ddolgov.remote.csb>
Precedence: bulk

> On Wed, Jan 05, 2022 at 10:11:11PM +0100, Dmitry Dolgov wrote:
> > On Tue, Jan 04, 2022 at 06:02:43PM -0500, Tom Lane wrote:
> > We can debate whether the rules proposed here are good for
> > pg_stat_statements or not, but it seems inevitable that they will be a
> > disaster for some other consumers of the query hash.
>
> Hm, which consumers do you mean here, potential extension? Isn't the
> ability to use an external module to compute queryid make this situation
> possible anyway?
>
> > do you really think that a query with two int
> > parameters is equivalent to one with five float parameters for all
> > query-identifying purposes?
>
> Nope, and it will be hard to figure this out no matter which approach
> we're talking about, because it mostly depends on the context and type
> of queries I guess. Instead, such functionality should allow some
> reasonable configuration. To be clear, the use case I have in mind here
> is not four or five, but rather a couple of hundreds constants where
> chances that the whole construction was generated automatically by ORM
> is higher than normal.
>
> > I can see the merits of allowing different numbers of IN elements
> > to be considered equivalent for pg_stat_statements, but this patch
> > seems to go far beyond that basic idea, and I fear the side-effects
> > will be very bad.
>
> Not sure why it goes far beyond, but then there were two approaches
> under consideration, as I've stated in the first message. I already
> don't remember all the details, but another one was evolving around
> doing similar things in a more limited fashion in transformAExprIn. The
> problem would be then to carry the information, necessary to represent
> the act of "merging" some number of queryids together. Any thoughts
> here?
>
> The idea of keeping the original queryid untouched and add another type
> of id instead sounds interesting, but it will add too much overhead for
> a quite small use case I guess.

```
Thu, 10 Mar 2022
New status: Waiting on Author
```

This seems incorrect, as the only feedback I've got was "this is a bad
idea", and no reaction on follow-up questions.