From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add os_page_num to pg_buffercache |
Date: | 2025-07-01 17:20:06 |
Message-ID: | aGQYxn/wmN9U50+l@ip-10-97-1-34.eu-west-3.compute.internal |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
> 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
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2025-07-01 17:46:30 | Re: Add os_page_num to pg_buffercache |
Previous Message | Jacob Champion | 2025-07-01 16:50:04 | Re: BackendKeyData is mandatory? |