Re: Add os_page_num to pg_buffercache - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Add os_page_num to pg_buffercache
Date
Msg-id b491a5da-3249-49f6-8c70-202d7d518ec3@vondra.me
Whole thread Raw
In response to Re: Add os_page_num to pg_buffercache  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On 7/1/25 19:20, Bertrand Drouvot wrote:
> Hi,
> 
> On Tue, Jul 01, 2025 at 06:45:37PM +0200, Tomas Vondra wrote:
>> On 7/1/25 18:34, Bertrand Drouvot wrote:
>>
>> But isn't the _numa view good enough for this? Sure, you need NUMA
>> support for it, and it may take a fair amount of time, but how often you
>> need to do such queries?
> 
> Not that often, but my reasoning was more like:
> 
> why people managing engines and/or developing on platform that does not support
> libnuma would not deserve access to this information?
> 

True. I always forget we only support libnuma on linux for now.

>> I don't plan to block improving this use case,
> 
> No worries at all, I do appreciate that you're looking at it and provide feedback
> whatever the outcome would be.
> 
>> but I'm not sure it's worth the effort.
> 
> I think that the hard work has already been done while creating
> pg_buffercache_numa_pages().
> 
> Now it's just a matter of extracting the necessary pieces from pg_buffercache_numa_pages()
> so that:
> 
> * the new view could make use of it
> * the maintenance burden should be low (thanks to code dedeuplication)
> * people that don't have access to a platform that supports libnuma can have
> access to this information
> 

+1


regards

-- 
Tomas Vondra




pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Add os_page_num to pg_buffercache
Next
From: Heikki Linnakangas
Date:
Subject: Re: Making Row Comparison NULL row member handling more robust during skip scans