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

From Kyotaro Horiguchi
Subject Re: WAL usage calculation patch
Date
Msg-id 20200403.104535.83950924251738205.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: WAL usage calculation patch  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: WAL usage calculation patch  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Hello.

The v13 patch seems failing to apply on the master.

At Fri, 3 Apr 2020 06:37:21 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in 
> On Thu, Apr 2, 2020 at 8:06 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Thu, Apr 2, 2020 at 6:41 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > 4.
> > > /* # of WAL full page image generated */
> > > Can we change it to "/* # of WAL full page image records generated */"?
> >
> > IMHO, "# of WAL full-page image records" seems like the number of wal
> > record which contains the full-page image.
> >
> 
> I think this resembles what you have written here.
> 
> >  But, actually, this is the
> > total number of the full-page images, not the number of records that
> > have a full-page image.
> >
> 
> We count this when forming WAL records.  As per my understanding, all
> three counters are about WAL records.  This counter tells how many
> records have full page images and one of the purposes of having this
> counter is to check what percentage of records contain full page
> image.

Aside from which is desirable or useful, acutually XLogRecordAssemble
in v13-0001 counts the number of attached images then XLogInsertRecord
sums up the number of images in pgWalUsage.wal_num_fpw.

FWIW, it seems to me that the main concern here is the source of WAL
size. If it is the case I think that the number of full page image is
more useful.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Next
From: Bryn Llewellyn
Date:
Subject: Syntax rules for a text value inside the literal for a user-defined type—doc section “8.16.2. Constructing Composite Values”