po 10. 5. 2021 v 19:03 odesÃlatel Maciek Sakrejda <m.sakre...@gmail.com> napsal:
> On Mon, May 10, 2021 at 7:43 AM Julien Rouhaud <rjuju...@gmail.com> wrote: > > On Mon, May 10, 2021 at 04:36:16PM +0200, Pavel Stehule wrote: > > > I expected just an empty column query_id and workable extension. This > > > doesn't look well. > > > > > > More, it increases the (little bit) complexity of migration to > Postgres 14. > > > > This was already raised multiple times, and the latest discussion can be > found > > at [1]. > > > > Multiple options have been suggested, but AFAICT there isn't a clear > consensus > > on what we should do exactly, so I've not been able to send a fix yet. > > > > [1]: > https://www.postgresql.org/message-id/flat/35457b09-36f8-add3-1d07-6034fa585ca8%40oss.nttdata.com > > Before it petered out, the thread seemed to be converging toward > consensus that the situation could be improved. I work on pganalyze, > and our product requires pg_stat_statements to be enabled for a lot of > its functionality. We guide our users through enabling it, but if > additional steps are required in 14, that may be confusing. I don't > have any strong feelings on the particular mechanism that would work > best here, but it would be nice if enabling pg_stat_statements in 14 > did not require more work than in 13. Even if it's just one extra > setting, it's another potential thing to get wrong and have to > troubleshoot, plus it means all existing pg_stat_statements guides out > there would become out of date. > +1 minimally it requires extra notes in some migration guide. I understand so queryid is one from key values. So it is not possible to merge data with and without a queryid. My idea about the best solution is something like pg_stat_statements can work without a queryid, and when the compute_query_id is changed, then the values stored in pg_stat_statements are resetted. I have no idea if it can be implemented. Current state is not user friendly. The people who know the previous behaviour can be very confused. Regards Pavel > Thanks, > Maciek >
