Re: [HACKERS] pg_stat_wal_write statistics view

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: [HACKERS] pg_stat_wal_write statistics view
Дата
Msg-id CAJrrPGfZK8sCnV4kw_C8jsMmRZcP3pP0=cxMo39bQUegEXOVRA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_stat_wal_write statistics view  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Ответы Re: [HACKERS] pg_stat_wal_write statistics view  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Список pgsql-hackers


On Tue, Sep 12, 2017 at 2:04 AM, Kuntal Ghosh <kuntalghosh.2007@gmail.com> wrote:
On Wed, Sep 6, 2017 at 9:16 AM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
>
> Attached the latest patch and performance report.
>
While looking into the patch, I realized that a normal backend has to
check almost 10 if conditions at worst case inside XLogWrite(6 in
am_background_process method, 1 for write, 1 for blocks, 2 for
fsyncs), just to decide whether it is a normal backend or not. The
count is more for walwriter process. Although I've not done any
performance tests, IMHO, it might add further overhead on the
XLogWrite Lock.

I was thinking whether it is possible to collect all the stats in
XLogWrite() irrespective of the type of backend and update the shared
counters at once at the end of the function. Thoughts?

Thanks for the review.
Yes, I agree with you that the stats update can be done at the end
of the function to avoid some overhead. Updated patch is attached.

There is an overhead with IO time calculation. Is the view is good 
enough without IO columns?

And also during my tests, I didn't observe any other background 
processes performing the xlogwrite operation, the values are always
zero. Is it fine to merge them with backend columns?

Regards,
Hari Babu
Fujitsu Australia
Вложения

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] Re: proposal - using names as primary names of plpgsqlfunction parameters instead $ based names
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] More flexible LDAP auth search filters?