Re: More problems with VacuumPageHit style global variables - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: More problems with VacuumPageHit style global variables
Date
Msg-id CAH2-Wz=n41wP5Utns2QzMAXgQGtLk4MnsS=SuRXwG13EG4ULFw@mail.gmail.com
Whole thread Raw
In response to Re: More problems with VacuumPageHit style global variables  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: More problems with VacuumPageHit style global variables
List pgsql-hackers
On Wed, Apr 20, 2022 at 7:50 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> As for your general question, I think you must be right.  From a quick
> rummage around in the commit log, it does appear that commit cddca5ec
> (2009), which introduced pgBufferUsage, always bumped the counters
> unconditionally.  It predated track_io_timing by years (40b9b957694
> (2012)), and long before that the Berkeley code already had a simpler
> thing along those lines (ReadBufferCount, BufferHitCount etc).  I
> didn't look up the discussion, but I wonder if the reason commit
> 9d3b5024435 (2011) introduced VacuumPage{Hit,Miss,Dirty} instead of
> measuring level changes in pgBufferUsage is that pgBufferUsage didn't
> have a dirty count until commit 2254367435f (2012), and once the
> authors had decided they'd need a new special counter for that, they
> continued down that path and added the others too?

I knew about pgBufferUsage, and I knew about
VacuumPage{Hit,Miss,Dirty} for a long time. But somehow I didn't make
the very obvious connection between the two until today. I am probably
not the only one.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: More problems with VacuumPageHit style global variables
Next
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Data is copied twice when specifying both child and parent table in publication