Re: Draft for basic NUMA observability - Mailing list pgsql-hackers
From | Bertrand Drouvot |
---|---|
Subject | Re: Draft for basic NUMA observability |
Date | |
Msg-id | Z+5FZbTxJSD6tqys@ip-10-97-1-34.eu-west-3.compute.internal Whole thread Raw |
In response to | Re: Draft for basic NUMA observability (Jakub Wartak <jakub.wartak@enterprisedb.com>) |
Responses |
Re: Draft for basic NUMA observability
Re: Draft for basic NUMA observability |
List | pgsql-hackers |
Hi, On Thu, Apr 03, 2025 at 09:01:43AM +0200, Jakub Wartak wrote: > On Wed, Apr 2, 2025 at 6:40 PM Tomas Vondra <tomas@vondra.me> wrote: > > Hi Tomas, > > > OK, so you agree the commit messages are complete / correct? > > Yes. Not 100% sure on my side. === v21-0002 Says: " This introduces three new functions: - pg_buffercache_init_entries - pg_buffercache_build_tuple - get_buffercache_tuple " While pg_buffercache_build_tuple() is not added (pg_buffercache_save_tuple() is). About v21-0002: === 1 I can see that the pg_buffercache_init_entries() helper comments are added in v21-0003 but I think that it would be better to add them in v21-0002 (where the helper is actually created). About v21-0003: === 2 > I hear you, attached v21 / 0003 is free of float/double arithmetics > and uses non-float point values. + if (buffers_per_page > 1) + os_page_query_count = NBuffers; + else + os_page_query_count = NBuffers * pages_per_buffer; yeah, that's more elegant. I think that it properly handles the relationships between buffer and page sizes without relying on float arithmetic. === 3 + if (buffers_per_page > 1) + { As buffers_per_page does not change, I think I'd put this check outside of the for (i = 0; i < NBuffers; i++) loop, something like: " if (buffers_per_page > 1) { /* BLCKSZ < PAGESIZE: one page hosts many Buffers */ for (i = 0; i < NBuffers; i++) { . . . . } else { /* BLCKSZ >= PAGESIZE: Buffer occupies more than one OS page */ for (i = 0; i < NBuffers; i++) { . . . " === 4 > That _numa_prepare_ptrs() is unused and will need to be removed, > but we can still move some code there if necessary. Yeah I think that it can be simply removed then. === 5 > @Bertrand: do you have anything against pg_shm_allocations_numa > instead of pg_shm_numa_allocations? I don't mind changing it... I think that pg_shm_allocations_numa() is better (given the examples you just shared). === 6 > I find all of those non-user friendly and I'm afraid I won't be able > to pull that alone in time... Maybe we could add a few words in the doc to mention the "multiple nodes per buffer" case? And try to improve it for say 19? Also maybe we should just focus till v21-0003 (and discard v21-0004 for 18). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
pgsql-hackers by date: