Re: pg_stat_wal_write statistics view

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_wal_write statistics view
Date: 2017-09-12 03:36:37
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Tue, Sep 12, 2017 at 2:04 AM, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>

> On Wed, Sep 6, 2017 at 9:16 AM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)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?

Hari Babu
Fujitsu Australia

Attachment Content-Type Size
0001-pg_stat_walwrites-statistics-view_v7.patch application/octet-stream 35.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2017-09-12 03:58:52 Re: More flexible LDAP auth search filters?
Previous Message Pavel Stehule 2017-09-12 03:14:44 Re: Re: proposal - using names as primary names of plpgsql function parameters instead $ based names