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. So users that want it can easily have it, and users that don't are not paying the price. For maximum user-friendliness, pg_stat_statement could be loaded and shmem-initialized even when query ID computation is turned off, and you'd be able to enable query ID computation with just SIGHUP; so you don't have to restart the server in order to enable statement tracking. (I suppose we would forbid users from disabling query ID with SET, though.)