Date: Tue, 26 Jul 2022 19:25:53 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
	"David G. Johnston" <david.g.johnston@gmail.com>,
	Pg Docs <pgsql-docs@lists.postgresql.org>
Subject: Re: documentation on HOT
Message-ID: <YuB4AcgNfSm13h3m@momjian.us>
References: 
 <CAKFQuwZHCbKYpEKEoQe=4Vf7JxTwVLbZdiLt-W+QgJsBN7wkzw@mail.gmail.com>
 <eead3a61-6c19-f5a8-ddfc-e895cb04657f@postgresql.org>
 <YtoFKu1D/KUo0ROb@momjian.us>
 <YtqdbfLYsULvY7HB@momjian.us>
 <d331a335-129f-66d9-e44c-4073119c9238@postgresql.org>
 <YtrZXSXJwWEyjQ37@momjian.us>
 <YtsSlrM7CqnsV23k@momjian.us>
 <CAH2-WznrTwM7iZ2_sHotqunBfLdCUD6y=uHJOzmVJ+NT46S0rg@mail.gmail.com>
 <YtwY9kBIY+73Oyk1@momjian.us>
 <CAH2-Wz=s-ThOH=p7YfWwcUhXsi4xeb_nJ+-MhSaJOaEgBkL+kw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAH2-Wz=s-ThOH=p7YfWwcUhXsi4xeb_nJ+-MhSaJOaEgBkL+kw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/YuB4AcgNfSm13h3m%40momjian.us>
Precedence: bulk

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

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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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