Thread: pg_stat_statements requires compute_query_id
Hi
I tested features of Postgres 14. The extension pg_stat_statements didn't work to me until I enabled compute_query_id. Is it expected behaviour?
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.
Regards
Pavel
Hi Pavel, On Mon, May 10, 2021 at 04:36:16PM +0200, Pavel Stehule wrote: > > I tested features of Postgres 14. The extension pg_stat_statements didn't > work to me until I enabled compute_query_id. Is it expected behaviour? Yes. > 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
On Mon, May 10, 2021 at 7:43 AM Julien Rouhaud <rjuju123@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. Thanks, Maciek
po 10. 5. 2021 v 19:03 odesílatel Maciek Sakrejda <m.sakrejda@gmail.com> napsal:
On Mon, May 10, 2021 at 7:43 AM Julien Rouhaud <rjuju123@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