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

From Andrey Borodin
Subject Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Date
Msg-id 9468F957-C0ED-4D72-8C89-61162CAA5591@yandex-team.ru
Whole thread Raw
In response to Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)  (Melanie Plageman <melanieplageman@gmail.com>)
List 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
indexscans 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@gmail.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
blockof 

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.


pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Refactor replication origin state reset helpers
Next
From: Hunaid Sohail
Date:
Subject: Re: Proposal: SELECT * EXCLUDE (...) command