Re: documentation on HOT

On Sat, Jul 23, 2022 at 11:33:40AM -0700, Peter Geoghegan 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."

Uh, that seems more confusing than what I have. I also considered
"tuples", but if you are saying "old version of a row", you are taking
about an old version of a logical row, not an old version of a physical
tuple, really.

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

Yes, if we were talking about tuples unrelated to the versions of the
rows they represent, then yes, it would make sense.

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

I ended up adding index cleanup further up in the text --- please see my
patch in the next email I send in this thread.
>
> * 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."

Same.

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

Yes, we need that, but not in this section --- I would like to it
though.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

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