Обсуждение: pg_stat_statements requires compute_query_id

Поиск
Список
Период
Сортировка

pg_stat_statements requires compute_query_id

От
Pavel Stehule
Дата:
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


Re: pg_stat_statements requires compute_query_id

От
Julien Rouhaud
Дата:
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



Re: pg_stat_statements requires compute_query_id

От
Maciek Sakrejda
Дата:
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



Re: pg_stat_statements requires compute_query_id

От
Pavel Stehule
Дата:


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