| 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.
| 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 |