Re: documentation on HOT

2022-07-21 Thread Bruce Momjian
On Sun, Feb  6, 2022 at 09:29:56PM -0500, Jonathan Katz wrote:
> I agree with Bruce's point that we should have a new section (or
> subsection). As I mentioned in my previous post, given HOT involves
> indexing, I would suggest putting it there.
> 
> I think that something that follows the general outline of Laurenz's post
> would satisfy the user requirements. It explains at a high level what HOT
> is, it's advantages, and how it works.

Attached is a patch that adds a new HOT section to the storage chapter.
You can see the results here:

https://momjian.us/tmp/pgsql/storage-hot.html

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson

diff --git a/doc/src/sgml/acronyms.sgml b/doc/src/sgml/acronyms.sgml
index 9ed148ab84..2df6559acc 100644
--- a/doc/src/sgml/acronyms.sgml
+++ b/doc/src/sgml/acronyms.sgml
@@ -299,9 +299,7 @@
 HOT
 
  
-  https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/heap/README.HOT;hb=HEAD;>Heap-Only
-  Tuples
+  Heap-Only Tuples
  
 

diff --git a/doc/src/sgml/btree.sgml b/doc/src/sgml/btree.sgml
index a9200ee52e..6f608a14bf 100644
--- a/doc/src/sgml/btree.sgml
+++ b/doc/src/sgml/btree.sgml
@@ -639,7 +639,8 @@ options(relopts local_relopts *) returns
accumulate and adversely affect query latency and throughput.  This
typically occurs with UPDATE-heavy workloads
where most individual updates cannot apply the
-   HOT optimization.  Changing the value of only
+   HOT optimization.
+   Changing the value of only
one column covered by one index during an UPDATE
always necessitates a new set of index tuples
 one for each and every index on the
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index a186e35f00..248dbc0e26 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -4381,7 +4381,7 @@ SCRAM-SHA-256$iteration count:
   
If true, queries must not use the index until the xmin
of this pg_index row is below their TransactionXmin
-   event horizon, because the table may contain broken HOT chains with
+   event horizon, because the table may contain broken HOT chains with
incompatible rows that they can see
   
  
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index e2d728e0c4..e5a84ed76d 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4482,7 +4482,8 @@ ANY num_sync ( HOT updates
+will defer cleanup of dead row versions. The
 default is zero transactions, meaning that dead row versions can be
 removed as soon as possible, that is, as soon as they are no longer
 visible to any open transaction.  You may wish to set this to a
diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml
index cf359fa9ff..4f83970c85 100644
--- a/doc/src/sgml/indexam.sgml
+++ b/doc/src/sgml/indexam.sgml
@@ -45,7 +45,8 @@
extant versions of the same logical row; to an index, each tuple is
an independent object that needs its own index entry.  Thus, an
update of a row always creates all-new index entries for the row, even if
-   the key values did not change.  (HOT tuples are an exception to this
+   the key values did not change.  (HOT
+   tuples are an exception to this
statement; but indexes do not deal with those, either.)  Index entries for
dead tuples are reclaimed (by vacuuming) when the dead tuples themselves
are reclaimed.
diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml
index 023157d888..42e1e86c8a 100644
--- a/doc/src/sgml/indices.sgml
+++ b/doc/src/sgml/indices.sgml
@@ -749,7 +749,7 @@ CREATE INDEX people_names ON people ((first_name || ' ' || last_name));
   
Index expressions are relatively expensive to maintain, because the
derived expression(s) must be computed for each row insertion
-   and non-HOT update.  However, the index expressions are
+   and non-HOT update.  However, the index expressions are
not recomputed during an indexed search, since they are
already stored in the index.  In both examples above, the system
sees the query as just WHERE indexedcolumn = 'constant'
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 7dbbab6f5c..6408d28c5d 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -4426,7 +4426,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
n_tup_upd bigint
   
   
-   Number of rows updated (includes HOT updated rows)
+   Number of rows updated (includes HOT updated rows)
   
  
 
diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml
index f4b9f66589..fec9e17985 100644
--- a/doc/src/sgml/storage.sgml
+++ b/doc/src/sgml/storage.sgml
@@ -1075,4 +1075,65 @@ data. Empty in ordinary tables.
  
 

Re: "Restore" vs. "Reload"

2022-07-21 Thread Bruce Momjian
On Thu, Jul 14, 2022 at 07:42:43PM -0400, Bruce Momjian wrote:
> On Wed, Mar 16, 2022 at 09:28:04AM +0100, Laurenz Albe wrote:
> > On Tue, 2022-03-15 at 16:12 +, PG Doc comments form wrote:
> > > Page: https://www.postgresql.org/docs/14/backup-dump.html
> > > 
> > > As far as I can see, the terms "Reload" and "Restore" are used
> > > interchangeably.
> > > To make the page as easy digestable for the reader as possible, it´s
> > > advisable to stick to exactly one term.
> > 
> > That makes sense, particularly since "reload" typically means something
> > else in PostgreSQL.  I think "restore" is better.
> > 
> > Do you feel like preparing a patch?
> 
> I have created the attached patch.  The only place I left "reload" was
> when it was used in pg_dump in "To reload an archive file" and similar
> cases.  In those cases, restoring a script or file might be
> misinterpreted.

Patch applied back to PG 11.  PG 10 had too many conflicts.

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson





Re: Documentation Suggestion

2022-07-21 Thread Bruce Momjian
On Thu, Jul 21, 2022 at 08:05:49PM +0200, Álvaro Herrera wrote:
> On 2022-Jul-21, Bruce Momjian wrote:
> 
> > Patch applied to all supported branches.
> 
> Thanks, looks good.
> 
> I notice you credited me as the reporter, but actually the reporter is
> jheb...@micron.com.

Oh, my apologies.  I had not kept the first email and didn't notice the
"Re:".
 
-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson





Re: Documentation Suggestion

2022-07-21 Thread Alvaro Herrera
On 2022-Jul-21, Bruce Momjian wrote:

> Patch applied to all supported branches.

Thanks, looks good.

I notice you credited me as the reporter, but actually the reporter is
jheb...@micron.com.

-- 
Álvaro Herrera   48°01'N 7°57'E  —  https://www.EnterpriseDB.com/




Re: Documentation Suggestion

2022-07-21 Thread Bruce Momjian
On Thu, Jul 14, 2022 at 06:23:43PM -0400, Bruce Momjian wrote:
> On Tue, May 24, 2022 at 08:36:18AM -0400, Bruce Momjian wrote:
> > fOn Sat, May 14, 2022 at 05:21:58PM +0200, Álvaro Herrera wrote:
> > > On 2022-May-13, Bruce Momjian wrote:
> > > > Note that valid --auth option values are all lower case, even
> > > > for authentication types that typically appear as all upper 
> > > > case,
> > > > e.g., "LDAP".
> > > 
> > > Yeah, that was my initial thought too.  The case-sensitivity is a
> > > consideration for other things too (such as locale or encoding names),
> > > but for those we do match the operating system name exactly, rather than
> > > using our own lower-case version of it, which nobody else uses.
> > > 
> > > So really the point is not about the fact that it is case sensitive as
> > > that the case of our name doesn't match the usual one.  Maybe the note
> > > should be "Note that authentication types are all lower case, [even for
> > > ...]" or something like that.
> 
> Here is a patch that implements this.

Patch applied to all supported branches.

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson