From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
cc: Julien Rouhaud <rjuju123@gmail.com>,
        torikoshia <torikoshia@oss.nttdata.com>,
        Atsushi Torikoshi <atorik@gmail.com>,
        Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>,
        Robert Haas <robertmhaas@gmail.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Michael Paquier <michael@paquier.xyz>,
        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: <20201005212406.GE4993@momjian.us>
References: <20200314175351.pihoihvko3xgywdn@nol>
 <20200316144312.sxg4zwbkfmdedh36@nol> <20200402132506.z43sg7ferqgmpthz@nol>
 <57df2441-f036-ba75-a374-c2e993015376@nttcom.co.jp_1>
 <CAOBaU_aRWVYoUdQ1i2DW_RqM8xACvWK2zyyucewHZfaqxjhQ_g@mail.gmail.com>
 <CACZ0uYFTCdujJc65qwGsotAGGGs5YROPbeFxMQBLz6ZcevmJBQ@mail.gmail.com>
 <20200714112453.hxxbwobyimefxzv7@nol>
 <a49fdf2ae0e3c22e1790c9bdb9cc520c@oss.nttdata.com>
 <CAOBaU_YjMKang71GkxFfZeWDgHPmyUV=KtRGGiwDeyNkkJfsPQ@mail.gmail.com>
 <20200819141930.n33w6qbap7udm7b6@nol> <20201005212406.GE4993@momjian.us>
Comments: In-reply-to Bruce Momjian <bruce@momjian.us>
	message dated "Mon, 05 Oct 2020 17:24:06 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1817288.1601934179.1@sss.pgh.pa.us>
Date: Mon, 05 Oct 2020 17:42:59 -0400
Message-ID: <1817289.1601934179@sss.pgh.pa.us>
Precedence: bulk

Bruce Momjian <bruce@momjian.us> writes:
> I would like to apply this patch (I know it has been in the commitfest
> since July 2019), but I have some questions about the user API.  Does it
> make sense to have a column in pg_stat_actvity and an option in
> log_line_prefix that will be empty unless pg_stat_statements is
> installed?  Is there no clean way to move the query hash computation out
> of pg_stat_statements and into the main code so the query id is always
> visible?  (Also, did we decide _not_ to make the pg_stat_statements
> queryid always a positive value?)

FWIW, I think this proposal is a mess.  I was willing to hold my nose
and have a queryId field in the internal Query struct without any solid
consensus about what its semantics are and which extensions get to use it.
Exposing it to end users seems like a bridge too far, though.  In
particular, I'm afraid that that will cause people to expect it to have
consistent values across PG versions, or even just across architectures
within one version.

The larger picture here is that there's lots of room to doubt whether
pg_stat_statements' decisions about what to ignore or include in the ID
will be satisfactory to everybody.  If that were not so, we'd just move
the computation into core.

			regards, tom lane