Re: [PATCH] Support for pg_stat_archiver view - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: [PATCH] Support for pg_stat_archiver view
Date
Msg-id CAHGQGwGNYLLr7vMVwrhjgkKCE5tvtNQ++iR-BHymrK90Sksz2g@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Support for pg_stat_archiver view  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Wed, Jan 29, 2014 at 12:35 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Jan 29, 2014 at 10:55 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Wed, Jan 29, 2014 at 3:07 AM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>>>
>>> Anybody knows about this patch?
>>> http://www.postgresql.org/message-id/508DFEC9.4020102@uptime.jp
>>
>> Though I'm not sure whether Nagayasu is still working on that patch,
>> it's worth thinking to introduce that together with pg_stat_archiver.
> This patch uses globalStats to implement the new stat fields for
> walwriter, I think that we should use a different structure for
> clarity and to be in-line with what is done now with the archiver
> part.

Is there clear reason why we should define separate structure for each
global stats view?
If we introduce something like pg_stat_walwriter later, it seems
better to use only one
structure, i.e., globalStats, for all global stats views. Which would
simplify the code and
can reduce the number of calls of fwrite()/fread().

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: WIP patch (v2) for updatable security barrier views
Next
From: Jeevan Chalke
Date:
Subject: Re: patch: option --if-exists for pg_dump