doc: index items for pg_stat_progress_xxx views
Hi, The index items for pg_stat_progress_xxx views point to the "Viewing Statistics" section, but not to the dedicated section (e.g., "ANALYZE Progress Reporting") for each view. IMO this is very inconvenient when finding the section describing each pg_stat_progress_xxx view, from the index. So what about adding new pointer to the section for each view in the index? Patch attached. BTW, other stats views have both pointers in the index. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml index 98e1995453..cc48c30ef3 100644 --- a/doc/src/sgml/monitoring.sgml +++ b/doc/src/sgml/monitoring.sgml @@ -5229,6 +5229,10 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid, ANALYZE Progress Reporting + + pg_stat_progress_analyze + + Whenever ANALYZE is running, the pg_stat_progress_analyze view will contain a @@ -5442,6 +5446,10 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid, CREATE INDEX Progress Reporting + + pg_stat_progress_create_index + + Whenever CREATE INDEX or REINDEX is running, the pg_stat_progress_create_index view will contain @@ -5738,6 +5746,10 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid, VACUUM Progress Reporting + + pg_stat_progress_vacuum + + Whenever VACUUM is running, the pg_stat_progress_vacuum view will contain @@ -5964,6 +5976,10 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid, CLUSTER Progress Reporting + + pg_stat_progress_cluster + + Whenever CLUSTER or VACUUM FULL is running, the pg_stat_progress_cluster view will @@ -6182,6 +6198,10 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid, Base Backup Progress Reporting + + pg_stat_progress_basebackup + + Whenever an application like pg_basebackup is taking a base backup, the
Re: Documentation of return values of range functions lower and upper
On Wed, 2020-11-11 at 18:19 +0100, Laurenz Albe wrote: > > Table 9.54 in page > > https://www.postgresql.org/docs/current/functions-range.html states that the > > functions lower and upper return NULL if the requested bound is infinite. If > > the element type of the range contains the special values infinity and > > -infinity, this is not correct, as those values are returned if explicitly > > used as either bound. > > +1 > > Perhaps it would be better to say > > NULL if the range is empty or has no lower/upper bound Here is a patch for this. Yours, Laurenz Albe From b17d2d968268257c5d1385bb834747fe3c33834b Mon Sep 17 00:00:00 2001 From: Laurenz Albe Date: Thu, 12 Nov 2020 09:13:09 +0100 Subject: [PATCH] Improve upper/lower documentation for ranges The old wording could give the impression that these functions would return NULL if the range is bounded by a value "infinity". Report by Jani Rahkola. Discussion: https://postgr.es/m/160508672127.25505.8356390205508789...@wrigleys.postgresql.org --- doc/src/sgml/func.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 2783985b55..d290653ae8 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -18176,7 +18176,7 @@ SELECT NULLIF(value, '(none)') ... Extracts the lower bound of the range (NULL if the -range is empty or the lower bound is infinite). +range is empty or has no lower bound). lower(numrange(1.1,2.2)) @@ -18194,7 +18194,7 @@ SELECT NULLIF(value, '(none)') ... Extracts the upper bound of the range (NULL if the -range is empty or the upper bound is infinite). +range is empty or has no upper bound). upper(numrange(1.1,2.2)) -- 2.26.2
Re: What does "[backends] should seldom or never need to wait for a write to occur" mean?
Hi Bruce, Thanks, yes I agree that that is much clearer. However when you say: When the percentage of dirty shared buffers is high, the background writer > writes some of them to the file system... I haven't seen anything about a minimum percentage before the bgwriter kicks in, is that really the case? How is it configured? Thanks, Chris. On Wed, 11 Nov 2020 at 23:24, Bruce Momjian wrote: > On Wed, Nov 11, 2020 at 11:29:09AM +, Chris Wilson wrote: > > I still believe that my original proposed change, to "This reduces the > chances > > that a backend needing an empty buffer must [itself] write a dirty one > back to > > disk before evicting it" (with one extra word added), resolves the > ambiguity > > and also more clearly and directly focuses it on what the bgwriter does > and > > why, making it better documentation. It might be incorrect if my > understanding > > is incorrect - is it? > > You make some very good points. Here is an updated patch. > > -- > Bruce Momjian https://momjian.us > EnterpriseDB https://enterprisedb.com > > The usefulness of a cup is in its emptiness, Bruce Lee > >
Re: What does "[backends] should seldom or never need to wait for a write to occur" mean?
On Thu, Nov 12, 2020 at 02:40:04PM +, Chris Wilson wrote: > Hi Bruce, > > Thanks, yes I agree that that is much clearer. However when you say: > > > When the percentage of dirty shared buffers is high, the background writer > writes some of them to the file system... > > > I haven't seen anything about a minimum percentage before the bgwriter kicks > in, is that really the case? How is it configured? Yes, I see your point. My language was not accurate, and it didn't match the actual background writer tuning parameters below this text. Here is an updated doc patch. I agree this text should be as clear as possible because there is no way to properly tune the background writer parameters unless we explain how it works. It is good you noticed this. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index f043433e31..8a29c90fdc 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2146,8 +2146,11 @@ include_dir 'conf.d' There is a separate server process called the background writer, whose function is to issue writes of dirty (new or modified) shared - buffers. It writes shared buffers so server processes handling - user queries seldom or never need to wait for a write to occur. + buffers. When the number of non-dirty shared buffers appears to be + insufficient, the background writer writes some dirty buffers to the + file system and marks them as clean. This reduces the likelihood + that server processes handling user queries will be unable to find + clean buffers and have to write dirty buffers themselves. However, the background writer does cause a net overall increase in I/O load, because while a repeatedly-dirtied page might otherwise be written only once per checkpoint interval, the
Re: What does "[backends] should seldom or never need to wait for a write to occur" mean?
On Thu, Nov 12, 2020 at 05:25:30PM +, Chris Wilson wrote: > Hi Bruce, > > Thanks, I absolutely agree that this documentation needs to explain properly > how the bgwriter works. Your latest patch looks good, it significantly > improves > this section of the manual. I would just suggest changing "non-dirty" to > "clean" in "When the number of non-dirty shared buffers appears to be > insufficient", as this makes the language simpler and avoids introducing > another new term (non-dirty, which means the same as clean). OK, done. I wasn't sure 'clean' would be assumed to be non-dirty, but you are right the language is clearer with 'clean'. (I was afraid 'clean' would be assumed to be 'empty'.) -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index f043433e31..a632cf98ba 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2146,8 +2146,11 @@ include_dir 'conf.d' There is a separate server process called the background writer, whose function is to issue writes of dirty (new or modified) shared - buffers. It writes shared buffers so server processes handling - user queries seldom or never need to wait for a write to occur. + buffers. When the number of clean shared buffers appears to be + insufficient, the background writer writes some dirty buffers to the + file system and marks them as clean. This reduces the likelihood + that server processes handling user queries will be unable to find + clean buffers and have to write dirty buffers themselves. However, the background writer does cause a net overall increase in I/O load, because while a repeatedly-dirtied page might otherwise be written only once per checkpoint interval, the
Re: What does "[backends] should seldom or never need to wait for a write to occur" mean?
Hi Bruce, Thanks, I absolutely agree that this documentation needs to explain properly how the bgwriter works. Your latest patch looks good, it significantly improves this section of the manual. I would just suggest changing "non-dirty" to "clean" in "When the number of non-dirty shared buffers appears to be insufficient", as this makes the language simpler and avoids introducing another new term (non-dirty, which means the same as clean). Thanks again, Chris. On Thu, 12 Nov 2020 at 16:54, Bruce Momjian wrote: > On Thu, Nov 12, 2020 at 02:40:04PM +, Chris Wilson wrote: > > Hi Bruce, > > > > Thanks, yes I agree that that is much clearer. However when you say: > > > > > > When the percentage of dirty shared buffers is high, the background > writer > > writes some of them to the file system... > > > > > > I haven't seen anything about a minimum percentage before the bgwriter > kicks > > in, is that really the case? How is it configured? > > Yes, I see your point. My language was not accurate, and it didn't > match the actual background writer tuning parameters below this text. > Here is an updated doc patch. > > I agree this text should be as clear as possible because there is no way > to properly tune the background writer parameters unless we explain how > it works. It is good you noticed this. > > -- > Bruce Momjian https://momjian.us > EnterpriseDB https://enterprisedb.com > > The usefulness of a cup is in its emptiness, Bruce Lee > >
Re: Missing file is mentioned on page https://www.postgresql.org/docs/13/libpq-exec.html
On Tue, Nov 10, 2020 at 07:23:12PM -0500, Bruce Momjian wrote: > On Tue, Nov 10, 2020 at 06:15:29PM -0500, Tom Lane wrote: > > Bruce Momjian writes: > > > On Fri, Oct 30, 2020 at 11:09:58AM -0400, Tom Lane wrote: > > >> Thinking about it from the perspective of someone dealing with an > > >> installation tree not a source tree, maybe the reference should > > >> be to "server/catalog/pg_type_d.h". That might help disabuse > > >> anyone who's expecting to find it at that path in the git tree. > > > > > I am confused what the "server/" prefix means in a path name. > > > > That is the path underneath the installation "include" directory > > at which that file will be found. > > Yep, it's there. I thought I checked for an include/catalog install > directory, but obviously not well enough. > > > > We currently say: > > > > > The OIDs of the built-in data types are defined in > > > the file src/include/catalog/pg_type_d.h in the > > > source tree. > > > > Yeah, so also s/source tree/install tree/. > > OK, here is a patch that mentions both. Adjusted patch applied to all branches. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
