Re: WAL usage calculation patch - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: WAL usage calculation patch
Date
Msg-id CAA4eK1JCkJFAx+hj3HS_MmM0nvnAphAZz1SubZMngOxNVy23=A@mail.gmail.com
Whole thread Raw
In response to Re: WAL usage calculation patch  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: WAL usage calculation patch  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Mon, Apr 6, 2020 at 1:53 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> On Mon, Apr 06, 2020 at 08:55:01AM +0530, Amit Kapila wrote:
> >
> > Here, we are not displaying Buffers related data, so why do we think
> > it is important to display WAL data?  I see some point in displaying
> > Buffers and WAL data in a vacuum (verbose), but I feel it is better to
> > make a case for both the statistics together rather than just
> > displaying one and leaving other.  I think the other change related to
> > autovacuum stats seems okay to me.
>
> One thing is that the amount of WAL, and more precisely FPW, is quite
> unpredictable wrt. vacuum and even more anti-wraparound vacuum, so this is IMHO
> a very useful metric.
>

I agree but we already have a way via pg_stat_statements to find it if
the metric is so useful.

>  That being said I totally agree with you that both
> should be displayed.  Should I send a patch to also expose it?
>

I think this should be a separate proposal.  Let's not add things
unless they are really essential.  We can separately discuss of
enhancing vacuum verbose for Buffer and WAL usage stats and see if
others also find that information useful.  I think you can send a
patch by removing the code I mentioned above if you agree.  Thanks for
working on this.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Optimizing RelationFindReplTupleSeq() for CLOBBER_CACHE_ALWAYS
Next
From: Amit Kapila
Date:
Subject: Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch)