Re: Draft for basic NUMA observability

From: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Draft for basic NUMA observability
Date: 2025-03-19 09:06:09
Message-ID: CAKZiRmyjWhuDRNSEHbCxiGqA-adSUB=DrSEVNfOQSLZ0eDNiAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 18, 2025 at 3:29 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:

Hi! v15 attached, rebased, CI-tested, all fixed incorporated.

> > I've adjusted it all and settled on "numa_node_id" column name.
>
[...]
> I think that we can get rid of the "numa_" stuff in column(s) name as
> the column(s) are part of "numa" relation views/output anyway.
[...]

Done, you are probably right (it was done to keep consistency between
those two views probably), I'm just not that strongly attached to the
naming things.

> > Please do such a check,
>
> Found much more:
>
[.. 9 issues with missing dots at the end of sentences in comments +
fixes to comment structure in relation to HEAD..]

All fixed.

> > BTW if patch has anything left that
> > causes pgident to fix, that is not picked by CI but it is picked by
> > buildfarm??
>
> I think it has to be done manually before each commit and that this is anyway
> done at least once per release cycle.

OK, thanks for clarification.

[..]
> >
> > But 0002 used:
> >
> > "In order to get reliable results we also need to touch memory pages, so that
> > inquiry about NUMA zone doesn't return -2 (which indicates
> > unmapped/unallocated
> > pages)"
> >
> > or are you looking at something different?
>
> Nope, I meant to say that it could make sense to have the exact same comment.

Synced those two.

[..]
>
> 0001 looks in a good shape from my point of view.

Cool!

> For 0002:
>
> === 1
>
> I wonder if pg_buffercache_init_entries() and pg_buffercache_build_tuple() could
> deserve their own patch. That would ease the review for the "real" numa stuff.
>

Done, 0001+0002 alone passes the meson test.

-J.

Attachment Content-Type Size
v15-0003-Extend-pg_buffercache-with-new-view-pg_buffercac.patch application/octet-stream 17.5 KB
v15-0001-Add-optional-dependency-to-libnuma-Linux-only-fo.patch application/octet-stream 18.8 KB
v15-0002-This-extracts-code-from-contrib-pg_buffercache-s.patch application/octet-stream 13.6 KB
v15-0004-Add-pg_shmem_numa_allocations-to-show-NUMA-memor.patch application/octet-stream 16.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikolay Shaplov 2025-03-19 09:15:24 Re: [PATCH] New [relation] option engine
Previous Message Shubham Khanna 2025-03-19 09:04:10 Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.