Re: documentation on HOT

On Sat, Jul 23, 2022 at 12:12:38PM -0700, David G. Johnston wrote:
> I concur, suggesting the following:
> 
> "Specifically, updates result in multiple rows versions (tuples) existing on
> the table."

See my reply to Peter G. about tuples.

> "There is sufficient free space on the page containing the old tuple for the
> updated tuple."

Same.

> "Old tuples can be completely removed..."

It is really old row versions, not old tuples since tuples, in my mind,
don't have a chain of versions.  There are cannot-be-viewed-by-anyone
tuples, but that is not the point here.

>     Overall, I think that this is suitable to commit, and I don't want to
>     make too much of a fuss. It's great that we're doing this.
> 
> 
> 
> Agreed.  The other suggestion listed are not clear-cut winners in my mind.
> 
> The following, though, seems to just come out of nowhere.  It would be better
> setup as a "(See <link> for why this is possible.)" instead of dropping "page
> item identifiers" on the reader.
> 
> +     This removal is possible because indexes
> +     do not reference their <link linkend="storage-page-layout">page
> +     item identifiers</link>.

I added parentheses around that.
> 
> As a related thought, this has done a great job of being usable for a DBA
> operating at a high-level of system knowledge and interaction.  I don't think
> burying it in storage.sgml is desirable,  Maybe "Performance Tips" under "Avoid
> Unnecessary Indexes" (yes, a bit of a stretch, but nothing else seems to fit
> better, except maybe in concurrency control since we are discussing overcoming
> the limitation of our concurrency control choice.

Uh, not sure.  Anyone else have an opinion?

> Summary paragraph:
> "can only happen if" => "can only be created if"

Yes, good point.

Updated patch attached.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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