Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Oct 16, 2020 at 01:03:55PM -0300, Álvaro Herrera wrote:
> On 2020-Oct-16, Bruce Momjian wrote:
> 
> > On Thu, Oct 15, 2020 at 11:41:23AM +0800, Julien Rouhaud wrote:
> 
> > > I did some naive benchmarking.  Using a custom pgbench script with this query:
> 
> > > I can see around 2% overhead (this query is reported with ~ 3ms
> > > latency average).  Adding a few joins, overhead goes down to 1%.
> > 
> > That number is too high to enable this by default.  I suggest we either
> > improve the performance of this, or clearly document that you have to
> > enable the hash computation to see the pg_stat_activity and
> > log_line_prefix fields.
> 
> Agreed.  This is similar to how we used to deal with query strings: an
> optional feature, disabled by default (cf.  commit b13c9686d084).
> 
> In this case, I suppose using pg_stat_statement would require to have it
> enabled, and it'd just not collect anything if disabled.  Similarly, the
> field would show NULL in pg_stat_activity or an empty string in
> log_line_prefix/CSV logs.

Yes, and at each use point, e.g., pg_stat_activity, log_line_prefix, we
have to remind people how to turn hash compuation on.

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

  The usefulness of a cup is in its emptiness, Bruce Lee