public inbox for [email protected]
help / color / mirror / Atom feedFrom: Dmitry Dolgov <[email protected]>
To: Tom Lane <[email protected]>
Cc: Zhihong Yu <[email protected]>
Cc: David Steele <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Greg Stark <[email protected]>
Cc: Pavel Trukhanov <[email protected]>
Subject: Re: pg_stat_statements and "IN" conditions
Date: Wed, 5 Jan 2022 22:11:11 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <20210105125230.etgmgixnn6fmpszl@localhost>
<CALNJ-vRRrdXu9igzh5PFTBghK5hnQWF6gpntTPo_+Agq_TsT5Q@mail.gmail.com>
<[email protected]>
<20210318155002.ggrgf2p2mvaodcox@localhost>
<20210615151850.6nsue7z5xjhpytle@localhost>
<20210616140212.kt3n5wi3alfz5i5d@localhost>
<20210930134930.d4vzwhvxhfpk2zxt@localhost>
<CALNJ-vSJvaJbcXr46JMyWFT5rO3BdaHO2E=xnAbLNDw1cyUJ-A@mail.gmail.com>
<20210930150957.tz3h3unjyrzatw6e@localhost>
<[email protected]>
> 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.
view thread (12+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: pg_stat_statements and "IN" conditions
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox