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

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, 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>, 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-16 13:05:44
Message-ID: 9468F957-C0ED-4D72-8C89-61162CAA5591@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>> In a step "Pass down information on table modification to scan node" you pass SO_HINT_REL_READ_ONLY flag in IndexNext() and BitmapTableScanSetup(), but not in IndexNextWithReorder() and IndexOnlyNext(). Is there a reason why index scans with ordering cannot use on-access VM setting?
>
> Great point, I simply hadn't tested those cases and didn't think to
> add them. I've added them in attached v33.
>
> While looking at other callers of index_beginscan(), I was wondering
> if systable_beginscan() and systable_beginscan_ordered() should ever
> pass SO_HINT_REL_READ_ONLY. I guess we would need to pass if the
> operation is read-only above the index_beginscan() -- I'm not sure if
> we always know in the caller of systable_beginscan() whether this
> operation will modify the catalog. That seems like it could be a
> separate project, though, so maybe it is better to say this feature is
> just for regular tables.

+1 for excluding catalog.

>
> As for the other cases: We don't have the relation range table index
> in check_exclusion_or_unique_constraints(), so I don't think we can do
> it there.
>
> And I think that the other index scan cases like in replication code
> or get_actual_variable_endpoint() are too small to be worth it, don't
> have the needed info, or don't do on-access pruning (bc of the
> snapshot type they use).

Makes sense. I think with cases that you already added the list is complete.

> On 6 Jan 2026, at 22:31, Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
>
> Let me know if there
> are other patches you reviewed that you did not mention.

I'll review them one by one, starting from first 3.

> <v33-0001-Combine-visibilitymap_set-cases-in-lazy_scan_pru.patch>

I agree that cases of visibilitymap_set() are merged properly.

I'm slightly worried that now if we decided to visibilitymap_set() all_frozen page it goes before corruption warning in block of

else if (all_visible_according_to_vm && !PageIsAllVisible(page) &&
visibilitymap_get_status(vacrel->rel, blkno, &vmbuffer) != 0)
{
}

Perhaps, it's not that important though. We are resetting everything to correct state anyway, just without WARNING.

> <v33-0002-Eliminate-use-of-cached-VM-value-in-lazy_scan_pr.patch>

LGTM. I'm actually happy with "else if (!PageIsAllVisible(page) &&..)" conversion to "if (!PageIsAllVisible(page) &&..)".

> <v33-0003-Refactor-lazy_scan_prune-VM-clear-logic-into-hel.patch>

LGTM.

I'll proceed with other steps later. Thanks!

Best regards, Andrey Borodin.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hunaid Sohail 2026-01-16 13:14:56 Re: Proposal: SELECT * EXCLUDE (...) command
Previous Message Ashutosh Bapat 2026-01-16 12:45:57 Re: Refactor replication origin state reset helpers