Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id YJ1kYeKvYBk0cxti@msg.df7cb.de
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Bruce Momjian <bruce@momjian.us>)
Responses Re: compute_query_id and pg_stat_statements
List pgsql-hackers
Re: Bruce Momjian
> Well, now that we have clear warnings when it is misconfigured,
> especially when querying the pg_stat_statements view, are these
> complaints still valid?   Also, how is modifying
> shared_preload_libraries zero-config, but modifying
> shared_preload_libraries and compute_query_id a huge burden?

It's zero-config in the sense that if you want to have
pg_stat_statements, loading that module via shared_preload_libraries
is just natural.

Having to set compute_query_id isn't natural. It's a setting with a
completely different name, and the connection of pg_stat_statements to
compute_query_id isn't obvious.

The reasoning with "we have warnings and stuff" might be ok if
pg_stat_statements were a new thing, but it has worked via
shared_preload_libraries only for the last decade, and requiring
something extra will confuse probably every single user of
pg_stat_statements out there.

Perhaps worse, note that these warnings will likely first be seen by
the end users of databases, not by the admin performing the initial
setup or upgrade, who will not be able to fix the problem themselves.

Christoph



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: compute_query_id and pg_stat_statements
Next
From: Bruce Momjian
Date:
Subject: Re: compute_query_id and pg_stat_statements