Date: Thu, 1 Apr 2021 15:27:11 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Hannu Krosing <hannuk@google.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Pavel Stehule <pavel.stehule@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>,
	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?
Message-ID: <20210401192711.GD18031@momjian.us>
References: <20210331130643.GA11608@momjian.us>
 <20210331141845.GA958@alvherre.pgsql>
 <20210401150524.ylqpsskvmnwsf6eg@nol>
 <20210401153015.kfyoxszzxtqum7os@nol>
 <20210401175642.GA18031@momjian.us>
 <20210401175915.GB18031@momjian.us>
 <20210401182802.d7o632hxdgwita32@nol>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210401182802.d7o632hxdgwita32@nol>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/20210401192711.GD18031%40momjian.us>
Precedence: bulk

On Fri, Apr  2, 2021 at 02:28:02AM +0800, Julien Rouhaud wrote:
> Unless I'm missing something query_string isn't a global variable, it's a
> parameter passed to exec_simple_query() from postgresMain().
> 
> It's then passed to the stats collector to be able to be displayed in
> pg_stat_activity through pgstat_report_activity() a bit like what I do for the
> queryid.
> 
> There's a global variable debug_query_string, but it's only for debugging
> purpose.
> 
> > > I wonder if the query hash
> > > should be a global variable too --- this would more clearly match how we
> > > handle top-level info like query_string.  Digging into the stats system
> > > to get top-level info does seem odd.
> 
> The main difference is that there's a single top level query_string,
> even if it contains multiple statements.  But there would be multiple queryid
> calculated in that case and we don't want to change it during a top level
> multi-statements execution, so we can't use the same approach.
> 
> Also, the query_string is directly logged from this code path, while the
> queryid is logged as a log_line_prefix, and almost all the code there also
> retrieve information from some shared structure.
> 
> And since it also has to be available in pg_stat_activity, having a single
> source of truth looked like a better approach.
> 
> > Also, if you go in that direction, make sure the hash it set in the same
> > places the query string is set, though I am unclear how extensions would
> > handle that.
> 
> It should be transparent for application, it's extracting the first queryid
> seen for each top level statement and export it.  The rest of the code still
> continue to see the queryid that corresponds to the really executed single
> statement.

OK, I am happy with your design decisions, thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.