MIME-Version: 1.0
References: <c59ffbd5-96ac-a5a5-a401-14f627ca1405@postgresql.org>
 <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>
In-Reply-To: <YtsSlrM7CqnsV23k@momjian.us>
From: Peter Geoghegan <pg@bowt.ie>
Date: Fri, 22 Jul 2022 15:33:20 -0700
Message-ID: 
 <CAH2-WznrTwM7iZ2_sHotqunBfLdCUD6y=uHJOzmVJ+NT46S0rg@mail.gmail.com>
Subject: Re: documentation on HOT
To: Bruce Momjian <bruce@momjian.us>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
 "David G. Johnston" <david.g.johnston@gmail.com>,
	Pg Docs <pgsql-docs@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAH2-WznrTwM7iZ2_sHotqunBfLdCUD6y%3DuHJOzmVJ%2BNT46S0rg%40mail.gmail.com>
Precedence: bulk

On Fri, Jul 22, 2022 at 2:11 PM Bruce Momjian <bruce@momjian.us> wrote:
> I have improved the wording of the last paragraph in this patch.

I think that it would be worth prominently explaining where heap-only
tuples get their name from: it comes from the fact there are (by
definition) no entries for a heap-only tuple in any index, ever.
Indexes are nevertheless capable of locating heap-only tuples during
index scans, by dealing with a little additional indirection: they
must traverse groups of related tuple versions, all for the same
logical row that was HOT updated one or more times -- this group of
related tuples is called a HOT chain.

This seems like a useful thing to emphasize because it places the
emphasis on what *doesn't* happen. Mostly what doesn't happen in
indexes.

New item identifiers actually *are* needed for heap-only tuples
(perhaps we could get away with it, but we don't). However, that
doesn't really matter too much in practice. Heap-only tuples can still
have their line pointers set to LP_UNUSED directly during pruning,
without having to be set to LP_DEAD for a time first (a situation
which VACUUM alone can correct by setting the LP_DEAD items to
LP_UNUSED during its second heap pass).

So heap-only tuples "skip the step" where they have to become LP_DEAD
stubs/tombstones. Which is possible precisely because indexes don't
need to be considered (they're "heap-only").

I agree that pruning should be discussed here, though -- I wouldn't go
as far as treating pruning as 100% unrelated to HOT. Perhaps something
along the lines of this works:

"It is possible for opportunistic pruning to completely remove all
bloat caused by HOT updates (bloat from HOT chains), without leaving
any residual garbage that only VACUUM is capable of cleaning up.
Pruning a page affected by non-HOT updates or deletes is somewhat less
effective, though, because small tombstone items (dead item
identifiers) must remain until such time as VACUUM can verify that no
remaining index tuples reference the items."

Again, the emphasis is on what *doesn't* have to happen because
indexes aren't making life hard for us. From the point of view of
indexes, ignorance is bliss. The really nice important point about
pruning and HOT is that it becomes possible (with care from the DBA
and application) to practically eliminate the role of VACUUM. We may
not even require a little help from VACUUM, under ideal conditions.

-- 
Peter Geoghegan