| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(at)vondra(dot)me>, David Rowley <dgrowleyml(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, 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-09-12 00:46:24 |
| Message-ID: | CAAKRu_Zy08CUHKWTSVXPe6orrcLAyQ6dAofda60Z7149Yz_PKQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 10, 2026 at 11:03 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> > <v1-0001-Make-on-access-pruning-pin-visibility-map-before-.patch>
>
> Looks reasonable to me to move visibilitymap_pin to before ConditionalLockBufferForCleanup. I saw the header comment of of visibilitymap_pin explicitly says that "Because that can require I/O to read the map page, you shouldn't hold a lock on the heap page while doing that.”.
Yea, that was my bad.
> I was thinking if we should unpin when ConditionalLockBufferForCleanup fails, but the new comment seems to resolve my confusion, because next heap page may map the same VM page.
Yea, we can most likely reuse it for the next page, so better not to
release it. It'll be cleaned upat the end of the query or if before
pinning a different page of the VM.
> So v1 LGTM.
Thanks. I've pushed it
- Melanie
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ZizhuanLiu X-MAN | 2026-09-12 01:54:56 | Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match |
| Previous Message | Bharath Rupireddy | 2026-09-12 00:40:41 | Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon |