| From: | 邱宇航 <iamqyh(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Aidar Imamov <a(dot)imamov(at)postgrespro(dot)ru>, Joseph Koshakow <koshy44(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-11-27 03:07:43 |
| Message-ID: | C13D309F-9B3B-4057-BC55-2F845056CA7E@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> It is a slightly disappointing that the loops for
> the buffers are duplicated, particularly for the relation vs the all
> case.
Yes, and we got another two loops in pg_buffercache_evict functions,
and more loops in Drop/Flush relation/database buffers functions. Maybe
we can abstract them into a generic loop function and it takes a buffer
handler function pointer to avoid duplication?
> One thing that would make more sense to me is to
> split the patch in two: one for the changes in bufmgr.c/h and one for
> pg_buffercache. There can be an argument that these new APIs could be
> useful for out-of-core code, as well, to let developers play with the
> state of the buffers. I mean, why not, the thread is also about API
> extensibility, as well, to enforce dirty states. :)
Agreed. It might be three, one for generic loop function, one for API
and one for pg_buffercache. If we put new API out-of-core, the latter
two can be merged.
Best regards,
Yuhang Qiu
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2025-11-27 03:10:08 | Re: Row pattern recognition |
| Previous Message | David Rowley | 2025-11-27 03:01:14 | Re: Partial hash index is not used for implied qual. |