Re: pg_stat_statements oddity with track = all

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: pg_stat_statements oddity with track = all
Дата
Msg-id 20210408120505.7zinijtdexbyghvb@nol
обсуждение исходный текст
Ответ на Re: pg_stat_statements oddity with track = all  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: pg_stat_statements oddity with track = all  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On Thu, Apr 08, 2021 at 10:30:53AM +0200, Magnus Hagander wrote:
> 
> I agree. If those numbers are indeed representable, it seems like
> better to pay that overhead than to pay the overhead of trying to
> de-dupe it.
> 
> Let's hope they are :)

:)

> Looking through ti again my feeling said the toplevel column should go
> after the queryid and not before, but I'm not going to open up a
> bikeshed over that.
> 
> I've added in a comment to cover that one that you removed (if you did
> send an updated patch as you said, then I missed it -- sorry), and
> applied the rest.

Oops, somehow I totally forgot to send the new patch, sorry :(

While looking at the patch, I unfortunately just realize that I unnecessarily
bumped the version to 1.10, as 1.9 was already new as of pg14.  Honestly I have
no idea why I used 1.10 at that time.  Version numbers are not a scarce
resource but maybe it would be better to keep 1.10 for a future major postgres
version?

If yes, PFA a patch to merge 1.10 in 1.9.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: PostgreSQL 14 Feature Freeze + Release Management Team (RMT)