RE: WIP: WAL prefetch (another approach) - Mailing list pgsql-hackers

From Shinoda, Noriyoshi (PN Japan FSIP)
Subject RE: WIP: WAL prefetch (another approach)
Date
Msg-id PH7PR84MB1885401C5FAECB66521E7F91EEED9@PH7PR84MB1885.NAMPRD84.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: WIP: WAL prefetch (another approach)  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: WIP: WAL prefetch (another approach)  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Hi, 
Thank you for developing the great feature. I tested this feature and checked the documentation. Currently, the
documentationfor the pg_stat_prefetch_recovery view is included in the description for the pg_stat_subscription view.
 

https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-SUBSCRIPTION

It is also not displayed in the list of "28.2. The Statistics Collector".
https://www.postgresql.org/docs/devel/monitoring.html

The attached patch modifies the pg_stat_prefetch_recovery view to appear as a separate view.

Regards,
Noriyoshi Shinoda
-----Original Message-----
From: Thomas Munro <thomas.munro@gmail.com> 
Sent: Friday, April 8, 2022 10:47 AM
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>; Stephen Frost <sfrost@snowman.net>; Andres Freund
<andres@anarazel.de>;Jakub Wartak <Jakub.Wartak@tomtom.com>; Alvaro Herrera <alvherre@2ndquadrant.com>; Tomas Vondra
<tomas.vondra@2ndquadrant.com>;Dmitry Dolgov <9erthalion6@gmail.com>; David Steele <david@pgmasters.net>; pgsql-hackers
<pgsql-hackers@postgresql.org>
Subject: Re: WIP: WAL prefetch (another approach)

On Fri, Apr 8, 2022 at 12:55 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> The docs seem to be wrong about the default.
>
> +        are not yet in the buffer pool, during recovery.  Valid values are
> +        <literal>off</literal> (the default), <literal>on</literal> and
> +        <literal>try</literal>.  The setting <literal>try</literal> 
> + enables

Fixed.

> +   concurrency and distance, respectively.  By default, it is set to
> +   <literal>try</literal>, which enabled the feature on systems where
> +   <function>posix_fadvise</function> is available.
>
> Should say "which enables".

Fixed.

> Curiously, I reported a similar issue last year.

Sorry.  I guess both times we only agreed on what the default should be in the final review round before commit, and I
letthe docs get out of sync (well, the default is mentioned in two places and I apparently ended my search too soon,
changingonly one).  I also found another recently obsoleted sentence: the one about showing nulls sometimes was no
longertrue.  Removed.
 



Attachment

pgsql-hackers by date:

Previous
From: Dong Wook Lee
Date:
Subject: GSoC: Improve PostgreSQL Regression Test Coverage
Next
From: Alvaro Herrera
Date:
Subject: Re: row filtering for logical replication