From: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
---|---|
To: | Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Aidar Imamov <a(dot)imamov(at)postgrespro(dot)ru>, Joseph Koshakow <koshy44(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache |
Date: | 2025-05-16 07:58:01 |
Message-ID: | CABPTF7WANOf_e-Um8Yz7KaBYqWYQ2t-7Zvm0Jjwaj_kDrRVOEA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hey,
I noticed a couple of small clarity issues in the current version of patch
for potential clean up:
1. Commit message wording
Right now it says:
“The pg_buffercache_mark_dirty_all() function provides an efficient way to
dirty the entire buffer pool (e.g., ~550 ms vs. ~70 ms for 16 GB of shared
buffers), complementing pg_buffercache_mark_dirty() for more granular
control.”
That makes it sound like the *_all* function is the granular one, when
really:
• pg_buffercache_mark_dirty(buffernumber) is the fine-grained, per-buffer
call.
• pg_buffercache_mark_dirty_all() is the bulk, coarse-grained operation.
How about rephrasing to:
“The pg_buffercache_mark_dirty_all() function provides an efficient, bulk
way to mark every buffer dirty (e.g., ~70 ms vs. ~550 ms for 16 GB of
shared buffers), while pg_buffercache_mark_dirty() still allows per-buffer,
granular control.”
2. Inline comment in MarkUnpinnedBufferDirty
We currently have:
PinBuffer_Locked(desc); */* releases spinlock */*
Folks who’re unfamiliar with this function might get confused. Maybe we
could use the one in GetVictimBuffer:
*/* Pin the buffer and then release its spinlock */*
PinBuffer_Locked(buf_hdr);
That spelling-out makes it obvious what’s happening.
> Since that patch is targeted for the PG 19, pg_buffercache is bumped to
> v1.7.
>
> Latest version is attached and people who already reviewed the patches are
> CCed.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2025-05-16 08:34:25 | Re: Virtual generated columns |
Previous Message | Richard Guo | 2025-05-16 07:26:01 | Re: Virtual generated columns |