Re: documentation on HOT

On Sat, Jul 23, 2022 at 11:34 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:

> On Sat, Jul 23, 2022 at 8:51 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Good points. I have updated the attached patch and URL to mention that
> > HOT rows are _completely_ removed, and why that is possible, and I
> > clarified the page item identifier mention.
>
> I think that this version looks very good, but I do have some minor notes:
>
> * You wrote "Specifically, updates cause additional rows to be added to
> tables."
>
> Perhaps this could be rephrased: "Specifically, updates add new
> physical tuples to tables to represent each new version."
>
> I think that the term "row" should only refer to the simple/abstract
> idea of a row from a table, while the term tuple should be preferred
> when referring to a physical embodiment of a row, like one version of
> a row. Perhaps it's worth following that convention across the board
> here (not just in this sentence that I have highlighted).
>

I concur, suggesting the following:

"Specifically, updates result in multiple rows versions (tuples) existing
on the table."

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

"Old tuples can be completely removed..."

> 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>.

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.

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

David J.