Re: Use pgstat_kind_infos to read fixed shared stats structs

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Use pgstat_kind_infos to read fixed shared stats structs
Дата
Msg-id ZjrTtJgJdaCaDBjm@paquier.xyz
обсуждение исходный текст
Ответ на Re: Use pgstat_kind_infos to read fixed shared stats structs  ("Tristan Partin" <tristan@neon.tech>)
Список pgsql-hackers
On Tue, May 07, 2024 at 02:07:42PM -0500, Tristan Partin wrote:
> On Tue May 7, 2024 at 1:29 PM CDT, Andres Freund wrote:
>> I think it's a good idea. I'd really like to allow extensions to register new
>> types of stats eventually. Stuff like pg_stat_statements having its own,
>> fairly ... mediocre, stats storage shouldn't be necessary.
>
> Could be useful for Neon in the future too.

Interesting thing to consider.  If you do that, I'm wondering if you
could, actually, lift the restriction on pg_stat_statements.max and
make it a SIGHUP so as it could be increased on-the-fly..  Hmm, just a
thought in passing.

>> Do we need to increase the stats version, I didn't check if the order we
>> currently store things in and the numerical order of the stats IDs are the
>> same.
>
> I checked the orders, and they looked the same.
>
> 1. Archiver
> 2. BgWriter
> 3. Checkpointer
> 4. IO
> 5. SLRU
> 6. WAL

Yup, I've looked at that yesterday and the read order remains the same
so I don't see a need for a version bump.
--
Michael

Вложения

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: backend stuck in DataFileExtend
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_sequence_last_value() for unlogged sequences on standbys