pg.ddx.io pgsql-hackers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: torikoshia <torikoshia@oss.nttdata.com>
Cc: Atsushi Torikoshi <atorik@gmail.com>
Cc: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Evgeny Efimkin <efimkin@yandex-team.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date: Mon, 12 Oct 2020 14:26:15 -0400
Message-ID: <3199563.1602527175@sss.pgh.pa.us> (raw)
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>
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
view thread (222+ messages) latest in thread
Message-ID: <3199563.1602527175@sss.pgh.pa.us> Permalink: ../3199563.1602527175@sss.pgh.pa.us/ Also on: postgresql.org/message-id/3199563.1602527175@sss.pgh.pa.us ·
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: pgsql-hackers@postgresql.org Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, bruce@momjian.us, rjuju123@gmail.com, michael@paquier.xyz, alvherre@alvh.no-ip.org, torikoshia@oss.nttdata.com, atorik@gmail.com, tatsuro.yamada.tf@nttcom.co.jp, tomas.vondra@2ndquadrant.com, efimkin@yandex-team.ru, pgsql-hackers@lists.postgresql.org Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? In-Reply-To: <3199563.1602527175@sss.pgh.pa.us> * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox