Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id 20210513173327.GD20766@tamriel.snowman.net
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: compute_query_id and pg_stat_statements
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > The only thing that bugs me is that we're pretty damn late in the
> > process to be engaging in this amount of design.
>
> Indeed.  I feel that this feature was forced in before it was really
> ready.

I'm coming around to have a similar feeling.  While having an
alternative query ID might be useful, I have a hard time seeing it as
likely to be a hugely popular feature that is worth a lot of users
complaining (as we've seen already, multiple times, before even getting
to beta...) that things aren't working anymore.  That we can't figure
out which libraries to load automatically based on what extensions have
been installed and therefore make everyone have to change
shared_preload_libraries isn't a good thing and requiring additional
configuration for extremely common extensions like pg_stat_statements is
making it worse.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: compute_query_id and pg_stat_statements
Next
From: Christoph Berg
Date:
Subject: Re: compute_query_id and pg_stat_statements