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

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Date: 2026-01-05 19:24:54
Message-ID: CAAKRu_bwtBEzDwemyim1r6yYonw7FTyFr1HXG8vywCe-MdbPBQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 3, 2026 at 4:36 PM Kirill Reshke <reshkekirill(at)gmail(dot)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 Content-Type Size
v32-0001-Combine-visibilitymap_set-cases-in-lazy_scan_pru.patch text/x-patch 10.2 KB
v32-0002-Eliminate-use-of-cached-VM-value-in-lazy_scan_pr.patch text/x-patch 16.9 KB
v32-0003-Refactor-lazy_scan_prune-VM-clear-logic-into-hel.patch text/x-patch 6.7 KB
v32-0004-Set-the-VM-in-heap_page_prune_and_freeze.patch text/x-patch 26.8 KB
v32-0005-Move-VM-assert-into-prune-freeze-code.patch text/x-patch 10.9 KB
v32-0006-Eliminate-XLOG_HEAP2_VISIBLE-from-vacuum-phase-I.patch text/x-patch 14.2 KB
v32-0007-Eliminate-XLOG_HEAP2_VISIBLE-from-empty-page-vac.patch text/x-patch 2.6 KB
v32-0008-Remove-XLOG_HEAP2_VISIBLE-entirely.patch text/x-patch 24.6 KB
v32-0009-Simplify-heap_page_would_be_all_visible-visibili.patch text/x-patch 2.4 KB
v32-0010-Remove-table_scan_analyze_next_tuple-unneeded-pa.patch text/x-patch 4.7 KB
v32-0011-Use-GlobalVisState-in-vacuum-to-determine-page-l.patch text/x-patch 11.9 KB
v32-0012-Unset-all_visible-sooner-if-not-freezing.patch text/x-patch 2.5 KB
v32-0013-Track-which-relations-are-modified-by-a-query.patch text/x-patch 2.6 KB
v32-0014-Pass-down-information-on-table-modification-to-s.patch text/x-patch 23.7 KB
v32-0015-Allow-on-access-pruning-to-set-pages-all-visible.patch text/x-patch 11.0 KB
v32-0016-Set-pd_prune_xid-on-insert.patch text/x-patch 6.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-01-05 20:19:00 Re: RFC: adding pytest as a supported test framework
Previous Message Masahiko Sawada 2026-01-05 19:16:34 Re: Support getrandom() for pg_strong_random() source