Re: Combine Prune and Freeze records emitted by vacuum

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: Combine Prune and Freeze records emitted by vacuum
Date: 2024-03-27 16:18:46
Message-ID: ff52c774-6129-428b-b478-d0b60431390b@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27/03/2024 17:18, Melanie Plageman wrote:
> I need some way to modify the control flow or accounting such that I
> know which HEAPTUPLE_RECENTLY_DEAD tuples will not be marked LP_DEAD.
> And a way to consider freezing and do live tuple accounting for these
> and HEAPTUPLE_LIVE tuples exactly once.

Just a quick update: I've been massaging this some more today, and I
think I'm onto got something palatable. I'll send an updated patch later
today, but the key is to note that for each item on the page, there is
one point where we determine the fate of the item, whether it's pruned
or not. That can happen in different points in in heap_page_prune().
That's also when we set marked[offnum] = true. Whenever that happens, we
all call one of the a heap_page_prune_record_*() subroutines. We already
have those subroutines for when a tuple is marked as dead or unused, but
let's add similar subroutines for the case that we're leaving the tuple
unchanged. If we move all the bookkeeping logic to those subroutines, we
can ensure that it gets done exactly once for each tuple, and at that
point we know what we are going to do to the tuple, so we can count it
correctly. So heap_prune_chain() decides what to do with each tuple, and
ensures that each tuple is marked only once, and the subroutines update
all the variables, add the item to the correct arrays etc. depending on
what we're doing with it.

--
Heikki Linnakangas
Neon (https://neon.tech)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2024-03-27 16:21:23 Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs
Previous Message Bertrand Drouvot 2024-03-27 16:12:23 Re: Introduce XID age and inactive timeout based replication slot invalidation