On Thu, Apr 3, 2025 at 1:52 PM Tomas Vondra <to...@vondra.me> wrote:
> On 4/3/25 09:01, Jakub Wartak wrote: > > On Wed, Apr 2, 2025 at 6:40 PM Tomas Vondra <to...@vondra.me> wrote: Hi Tomas, Here's v23 attached (had to rework it because the you sent v22 just the moment you I wanted to send it) Change include: - your review should be incorporated - name change for shm view - pg_buffercache_numa refactor a little to keep out the if outside loops (as Bertrand wanted initially) So let's continue in this subthread. > I think a view with just 3 columns would be a good solution. It's what > pg_shmem_allocations_numa already does, so it'd be consistent with that > part too. > > I'm not too worried about the cost of the extra join - it's going to be > a couple dozen milliseconds at worst, I guess, and that's negligible in > the bigger scheme of things (e.g. compared to how long the move_pages is > expected to take). Also, it's not like having everything in the same > view is free - people would have to do some sort of post-processing, and > that has a cost too. > > 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. > I'm -1 on JSON, I don't see how would that solve anything better than > e.g. a regular array, and it's going to be harder to work with. So if we > don't want to go with the 3-column view proposed earlier, I'd stick to a > simple array. I don't think there's a huge difference between those two > approaches, it should be easy to convert between those approaches using > unnest() and array_agg(). > > Attached is v22, with some minor review comments: > > 1) I suggested we should just use "libnuma support" in configure, > instead of talking about "NUMA awareness support", and AFAICS you > agreed. But I still see the old text in configure ... is that > intentional or a bit of forgotten text? It was my bad, too many rebases and mishaps with git voodoo.. > 2) I added a couple asserts to pg_buffercache_numa_pages() and comments, > and simplified a couple lines (but that's a matter of preference). Great, thanks. > 3) I don't think it's correct for pg_get_shmem_numa_allocations to just > silently ignore nodes outside the valid range. I suggest we simply do > elog(ERROR), as it's an internal error we don't expect to happen. It's there too. -J.
v23-0001-Add-support-for-basic-NUMA-awareness.patch
Description: Binary data
v23-0004-Add-new-pg_shmem_allocations_numa-view.patch
Description: Binary data
v23-0002-pg_buffercache-split-pg_buffercache_pages-into-p.patch
Description: Binary data
v23-0003-Add-pg_buffercache_numa-view-with-NUMA-node-info.patch
Description: Binary data
