From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Bruce Momjian <bruce@momjian.us>, Julien Rouhaud <rjuju123@gmail.com>,
        Michael Paquier <michael@paquier.xyz>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        torikoshia <torikoshia@oss.nttdata.com>,
        Atsushi Torikoshi <atorik@gmail.com>,
        Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Evgeny Efimkin <efimkin@yandex-team.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Feature improvement: can we add queryId for
 pg_catalog.pg_stat_activity view?
In-reply-to: 
 <CA+TgmoaK55MiAU1wxizK05ZkxK8KKj83P2WxWCTQ7LLe9P6RCA@mail.gmail.com>
References: <1817289.1601934179@sss.pgh.pa.us>
 <20201005225842.GA8918@alvherre.pgsql> <20201006021819.GA10975@momjian.us>
 <CAOBaU_axtsj8Ad07wPrr0Way---+v0pz3BnXa_m2xuCKE32Y0Q@mail.gmail.com>
 <20201006032350.GA3686@momjian.us> <20201006053458.GA429@paquier.xyz>
 <20201006132229.GB3686@momjian.us> <20201007014249.GB2256@paquier.xyz>
 <20201007015346.GF12277@momjian.us>
 <CAOBaU_bt3-CwkAQLu7kUp-Yy7dyjhTntNG7Q30CssJHjaPYKEQ@mail.gmail.com>
 <20201012141445.GA24889@momjian.us>
 <CA+TgmoaK55MiAU1wxizK05ZkxK8KKj83P2WxWCTQ7LLe9P6RCA@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 12 Oct 2020 13:30:50 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3199562.1602527175.1@sss.pgh.pa.us>
Date: Mon, 12 Oct 2020 14:26:15 -0400
Message-ID: <3199563.1602527175@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> I don't really understand how a version number helps. It's not like
> there is going to be a v2 that is in all ways better than v1. If there
> are different algorithms here, they are going to be customized for
> different needs.

Yeah, I agree --- a version number is the wrong way to think about this.
It's gonna be more like algorithm foo versus algorithm bar versus
algorithm baz, where each one is better for a specific set of use-cases.
Julien already noted the point about hashing object OIDs versus object
names; one can easily imagine disagreeing with pg_stat_statement's
choices about ignoring values of constants; other properties of statements
might be irrelevant for some use-cases; and so on.

I'm okay with moving pg_stat_statement's existing algorithm into core as
long as there's a way for extensions to override it.  With proper design,
that would allow extensions that do override it to coexist with
pg_stat_statements (thereby redefining the latter's idea of which
statements are "the same"), which is something that doesn't really work
nicely today.

			regards, tom lane