Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Mon, Apr 26, 2021 at 6:56 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Stephen Frost <sfr...@snowman.net> writes: > > > * Bruce Momjian (br...@momjian.us) wrote: > > >> Techically, pg_stat_statements can turn on compute_query_id when it is > > >> loaded, even if it is 'off' in postgresql.conf, right? And > > >> pg_stat_statements would know if an alternate hash method is being used, > > >> right? > > > > > +1 on this approach. > > > > That'd make it impossible to turn off or adjust afterwards, wouldn't it? > > I'm afraid the confusion stemming from that would outweigh any simplicity.
I don't know that it actually would, but ... > Thatäs why I suggested the three value one. Default to a mode where > it's automatic, which is what the majority is going to want, but have > a way to explicitly turn it on. This is certainly fine with me too, though it seems a bit surprising to me that we couldn't just figure out what the user actually wants based on what's installed/running for any given combination. > > In the end, it's not like this is the first time we've ever made an > > incompatible change in configuration needs; and it won't be the last > > either. I don't buy the argument that pg_stat_statements users can't > > cope with adding the additional setting. (Of course, we should be > > careful to call it out as an incompatible change in the release notes.) > > The fact that we've made changes before that complicated our users > experience isn't in itself an argument for doing it again though... I'm generally a proponent of sensible changes across major versions even if it means that the user has to adjust things, but this seems like a case where we're punting on something that we really should just be able to figure out the right answer to and that seems like a step backwards. Thanks, Stephen
signature.asc
Description: PGP signature
