Re: pg_stat_io not tracking smgrwriteback() is confusing

Поиск
Список
Период
Сортировка
От Jonathan S. Katz
Тема Re: pg_stat_io not tracking smgrwriteback() is confusing
Дата
Msg-id 031a2857-6c21-3a5c-1647-465a13794429@postgresql.org
обсуждение исходный текст
Ответ на Re: pg_stat_io not tracking smgrwriteback() is confusing  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers

On 4/24/23 6:14 PM, Andres Freund wrote:
> Hi,
> 
> On 2023-04-24 10:52:15 +0530, Amit Kapila wrote:
>> On Sun, Apr 23, 2023 at 12:55 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>>>> I wonder if it's
>>>> worth doing so for 16? It'd give a more complete picture that way. The
>>>> counter-argument I see is that we didn't track the time for it in existing
>>>> stats either, and that nobody complained - but I suspect that's mostly because
>>>> nobody knew to look.
>>>
>>> [RMT hat]
>>>
>>> (sorry for slow reply on this, I've been out for a few days).
>>>
>>> It does sound generally helpful to track writeback to ensure anyone
>>> building around pg_stat_io can see tthe more granular picture. How big
>>> of an effort is this?
>>>
>>
>> Right, I think this is the key factor to decide whether we can get
>> this in PG16 or not. If this is just adding a new column and a few
>> existing stats update calls then it should be okay to get in but if
>> this requires some more complex work then we can probably update the
>> docs.
> 
> I suspect it should really just be adding a few stats calls. The only possible
> complication that I can see is that we might need to pass a bit more context
> down in a place or two.

OK. So far it sounds reasonable to include. I think we should add this 
as an open item. I don't know if we need to set a deadline just yet, but 
we should try to keep go/nogo to earlier in the beta cycle.

Thanks,

Jonathan



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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Request for comment on setting binary format output per session
Следующее
От: Andres Freund
Дата:
Сообщение: Re: base backup vs. concurrent truncation