On 4/3/25 15:12, Jakub Wartak wrote:
> On Thu, Apr 3, 2025 at 1:52 PM Tomas Vondra <tomas@vondra.me> wrote:
>
>> ...
>>
>> So unless someone can demonstrate a use case where this would matter,
>> I'd not worry about it too much.
>
> OK, fine for me - just 3 cols for pg_buffercache_numa is fine for me,
> it's just that I don't have cycles left today and probably lack skills
> (i've never dealt with arrays so far) thus it would be slow to get it
> right... but I can pick up anything tomorrow morning.
>
OK, I took a stab at reworking/simplifying this the way I proposed.
Here's v24 - needs more polishing, but hopefully enough to show what I
had in mind.
It does these changes:
1) Drops 0002 with the pg_buffercache refactoring, because the new view
is not "extending" the existing one.
2) Reworks pg_buffercache_num to return just three columns, bufferid,
page_num and node_id. page_num is a sequence starting from 0 for each
buffer.
3) It now builds an array of records, with one record per buffer/page.
4) I realized we don't really need to worry about buffers_per_page very
much, except for logging/debugging. There's always "at least one page"
per buffer, even if an incomplete one, so we can do this:
os_page_count = NBuffers * Max(1, pages_per_buffer);
and then
for (i = 0; i < NBuffers; i++)
{
for (j = 0; j < Max(1, pages_per_buffer); j++)
{
..
}
}
and everything just works fine, I think.
Opinions? I personally find this much cleaner / easier to understand.
regards
--
Tomas Vondra
