public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bruce Momjian <[email protected]>
To: Peter Geoghegan <[email protected]>
Cc: Jonathan S. Katz <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: Pg Docs <[email protected]>
Subject: Re: documentation on HOT
Date: Tue, 26 Jul 2022 19:25:53 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAH2-Wz=s-ThOH=p7YfWwcUhXsi4xeb_nJ+-MhSaJOaEgBkL+kw@mail.gmail.com>
References: <CAKFQuwZHCbKYpEKEoQe=4Vf7JxTwVLbZdiLt-W+QgJsBN7wkzw@mail.gmail.com>
	<[email protected]>
	<YtoFKu1D/[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAH2-WznrTwM7iZ2_sHotqunBfLdCUD6y=uHJOzmVJ+NT46S0rg@mail.gmail.com>
	<[email protected]>
	<CAH2-Wz=s-ThOH=p7YfWwcUhXsi4xeb_nJ+-MhSaJOaEgBkL+kw@mail.gmail.com>

On Sat, Jul 23, 2022 at 11:33:40AM -0700, Peter Geoghegan wrote:
> On Sat, Jul 23, 2022 at 8:51 AM Bruce Momjian <[email protected]> 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  <[email protected]>        https://momjian.us
  EDB                                      https://enterprisedb.com

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

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: documentation on HOT
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox