Hi,
On Tue, Mar 04, 2025 at 11:48:31AM +0100, Jakub Wartak wrote:
> Hi!
>
> On Thu, Feb 27, 2025 at 4:34 PM Bertrand Drouvot
> <bertranddrouvot...@gmail.com> wrote:
>
> > I did some tests and it looks like it's giving correct results. I don't see
> > -2
> > anymore and every backend reports correct distribution (with or without hp,
> > with "small" or "large" shared buffer).
>
> Cool! Attached is v7
Thanks for the new version!
> > === 2
> >
> > + if (query_numa)
> > + {
> > + blk2page = (int) i * pages_per_blk;
> > + j = 0;
> > + do
> > + {
> >
> > This check is done for every page. I wonder if it would not make sense
> > to create a brand new function for pg_buffercache_numa and just let the
> > current pg_buffercache_pages() as it is. That said it would be great to
> > avoid
> > code duplication as much a possible though, maybe using a shared
> > populate_buffercache_entry() or such helper function?
>
> Well, I've made query_numa a parameter there simply to avoid that code
> duplication in the first place, look at those TupleDescInitEntry()...
Yeah, that's why I was mentioning to use a "shared" populate_buffercache_entry()
or such function: to put the "duplicated" code in it and then use this
shared function in pg_buffercache_pages() and in the new numa related one.
> IMHO rarely anybody uses pg_buffercache, but we could add unlikely()
I think unlikely() should be used for optimization based on code path
likelihood,
not based on how often users might use a feature.
> > === 5
> >
> > Could we also avoid some code duplication with pg_get_shmem_allocations()?
>
> Not sure I understand do you want to avoid code duplication
> pg_get_shmem_allocations() vs pg_get_shmem_numa_allocations() or
> pg_get_shmem_numa_allocations() vs pg_buffercache_pages(query_numa =
> true) ?
I meant to say avoid code duplication between pg_get_shmem_allocations() and
pg_get_shmem_numa_allocations(). It might be possible to create a shared
function for them too. That said, it looks like that the savings (if any), would
not be that much, so maybe just forget about it.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
