Re: Emit fewer vacuum records by reaping removable tuples during pruning

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Emit fewer vacuum records by reaping removable tuples during pruning
Дата
Msg-id CAH2-WzntVO-zzA9=ZvLB2zBrq9oSrz-vcMgRsgFa7LCAKn=rdw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Emit fewer vacuum records by reaping removable tuples during pruning  (Melanie Plageman <melanieplageman@gmail.com>)
Список pgsql-hackers
On Fri, Jan 5, 2024 at 12:59 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> > But you can just as easily turn this argument on its head, can't you?
> > In general, except for HOT tuples, line pointers are marked dead by
> > pruning and unused by vacuum. Here you want to turn it on its head and
> > make pruning do what would normally be vacuum's responsibility.
>
> I actually think we are going to want to stop referring to these steps
> as pruning and vacuuming. It is confusing because vacuuming refers to
> the whole process of doing garbage collection on the table and also to
> the specific step of setting dead line pointers unused. If we called
> these steps say, pruning and reaping, that may be more clear.

What about index VACUUM records? Should they be renamed to REAP records, too?

> Vacuuming consists of three phases -- the first pass, index vacuuming,
> and the second pass. I don't think we should dictate what happens in
> each pass. That is, we shouldn't expect only pruning to happen in the
> first pass and only reaping to happen in the second pass.

Why not? It's not self-evident that it matters much either way. I
don't see it being worth the complexity (which is not to say that I'm
opposed to what you're trying to do here).

Note that we only need a cleanup for the first heap pass right now
(not the second heap pass). So if you're going to prune in the second
heap pass, you're going to have to add a mechanism that makes it safe
(by acquiring a cleanup lock once we decide that we actually want to
prune, say). Or maybe you'd just give up on the fact that we don't
need cleanup locks for the second hea pass these days instead (which
seems like a step backwards).

> For example,
> I think Andres has previously proposed doing another round of pruning
> after index vacuuming. The second pass/third phase is distinguished
> primarily by being after index vacuuming.

I think of the second pass/third phase as being very similar to index vacuuming.

Both processes/phases don't require cleanup locks (actually nbtree
VACUUM does require cleanup locks, but the reasons why are pretty
esoteric, and not shared by every index AM). And, both
processes/phases don't need to generate their own recovery conflicts.
Neither type of WAL record requires a snapshotConflictHorizon field of
its own, since we can safely assume that some PRUNE record must have
taken care of all that earlier on.

--
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Fix bogus Asserts in calc_non_nestloop_required_outer
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: add AVX2 support to simd.h