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 <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
