Re: pg_stat_statements and "IN" conditions - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: pg_stat_statements and "IN" conditions
Date
Msg-id CAA5RZ0tbcQoFmMCQh3nNSg5dKsuepa9-uTfYXTMXxdU+Xi9KhA@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_statements and "IN" conditions  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: pg_stat_statements and "IN" conditions
Re: pg_stat_statements and "IN" conditions
List pgsql-hackers
I have only looked at 0001, but I am wondering why
query_id_const_merge is a pg_stat_statements GUC
rather than a core GUC?

The dependency of pg_stat_statements to take advantage
of this useful feature does not seem right.

For example if the user does not have pg_stat_statements enabled,
but are sampling top queryId from pg_stat_activity, they will
likely want this merge behavior to build meaningful database
load graphs.

Other extensions that consume queryIds may also want this
behavior without needing to enable pg_stat_statements.

Also, we have compute_query_id as a core parameter, this
new guc will become an option for how to compute a queryId.
In the future we may want to introduce other controls for how a
queryId is generated.

Regards,

Sami



pgsql-hackers by date:

Previous
From: "Euler Taveira"
Date:
Subject: Re: Small memory fixes for pg_createsubcriber
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] snowball: fix potential NULL dereference