Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Date
Msg-id CAAKRu_bwtBEzDwemyim1r6yYonw7FTyFr1HXG8vywCe-MdbPBQ@mail.gmail.com
Whole thread Raw
In response to Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)  (Kirill Reshke <reshkekirill@gmail.com>)
Responses Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
List pgsql-hackers
On Sat, Jan 3, 2026 at 4:36 PM Kirill Reshke <reshkekirill@gmail.com> wrote:
>
> After thinking about it for a week or so, I would actually suggest
> moving forward with v31 (Remove OldestXmin from TAM).
> I think this is a low probability of getting complaints about that.
> Also, we're breaking ABI, so we will know about any important use-case
> not long after 19-beta1.
> Another user of extensible TAM, Cloudberry [0], does not use
> OldestXmin also. I also did not find any user of
> scan_analyze_next_tuple other than postgresql itself with
> http://codesearch.decbian.net/ . Using code-search on github I found
> [1]. Looks like this does not need OldestXmin either.

Thanks for doing this research.

I've attached v32 which is rebased over a change in master and also
resolves the one open issue in the patch set: why the killtuples
isolation test heap accesses count changed after setting pd_prune_xid.

That test creates a table, inserts tuples, accesses one page, deletes
all the data, accesses a single page again (until the table is
vacuumed, the pages will still be there and have to be scanned even
though the data is deleted). The first time we set the VM on-access,
we have to extend the VM. That VM access is an extend and not a hit.
Once we set pd_prune_xid on the page, the extend happens during the
first access (before the delete), so when we access the VM after the
delete step, that is counted as a hit and we end up with more hits in
the stats.

- Melanie

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Support getrandom() for pg_strong_random() source
Next
From: Jacob Champion
Date:
Subject: Re: RFC: adding pytest as a supported test framework