Re: documentation on HOT

On Sat, Jul 23, 2022 at 8:51 AM Bruce Momjian <bruce@momjian.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).

* You wrote "This can also require new index entries for each updated
row, and removal of old versions of rows can be expensive"

I believe that the operative word in this sentence (which appears in
the first paragraph) is "can". I think that it would be good to go
just a bit further with that. Maybe add another sentence immediately
afterwards that conveys "and now we're going to discuss when and how
new versions from updates can sometimes avoid the need for a new round
of index entries".

* You wrote "New index entries are not needed to represent updated rows"

It seems to me that this undersells the key benefit. You could perhaps
add another sentence. Something like: "This avoids the immediate cost
of adding new successor versions to each and every index, and avoids
the cost of removing the obsolete versions from each and every index
later on."

* You refer to opportunistic pruning as something that happens "during
normal operation", but that doesn't seem to get the idea of
"opportunistic" across.

It seems like it would be worth writing a sentence or two more on
this, just to get that aspect across. Opportunistic cleanup occurs
when a query happens to notice that a heap page that it had to read as
part of query processing needed to be cleaned up in passing. We do it
there and then because it happens to be relatively cheap and
convenient to do it that way. That sort of thing.

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.

Thanks
-- 
Peter Geoghegan