Re: Add os_page_num to pg_buffercache
От | Bertrand Drouvot |
---|---|
Тема | Re: Add os_page_num to pg_buffercache |
Дата | |
Msg-id | aH4Emphowm1I5Oqe@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответ на | Re: Add os_page_num to pg_buffercache (Mircea Cadariu <cadariu.mircea@gmail.com>) |
Ответы |
Re: Add os_page_num to pg_buffercache
|
Список | pgsql-hackers |
Hi, On Wed, Jul 09, 2025 at 10:51:16AM +0100, Mircea Cadariu wrote: > If you don't mind I have some further questions on the patch, see below. Thanks for the feedback/questions! > > + if (get_call_result_type(fcinfo, NULL, &expected_tupledesc) != TYPEFUNC_COMPOSITE) > > + elog(ERROR, "return type must be a row type"); > > Is this needed in the new pg_buffercache_os_pages function? Strictly speaking it is not, we could CreateTemplateTupleDesc(NUM_BUFFERCACHE_OS_PAGES_ELEM) instead of CreateTemplateTupleDesc(expected_tupledesc->natts). OTOH, it's used in multiple places in this extension so I think it's ok to keep it that way for consistency. > I noticed this > check also in the "original" pg_buffercache_pages. There's a comment there > indicating that (if I understand correctly) its purpose is to handle > upgrades from version 1.0, mentioning a field unrelated to this patch. > > If it's needed, shall we consider adding a similar comment as > in pg_buffercache_pages? We don't need the same kind of comment in pg_buffercache_os_pages() because it's new in 1.7 (so the patch can not "break" a pre-1.7 version of this function /view). In the pg_buffercache_pages case, the story is different, it's used to deal with the pinning_backends fields that has been introduced in 1.1 (see pg_buffercache--1.0--1.1.sql). > > + /* > > + * Different database block sizes (4kB, 8kB, ..., 32kB) can be used, > > + * while the OS may have different memory page sizes. > > + * > > + * To correctly map between them, we need to: 1. Determine the OS > > + * memory page size 2. Calculate how many OS pages are used by all > > + * buffer blocks 3. Calculate how many OS pages are contained within > > + * each database block. > > + */ > For step number 3 - should it be the other way around: database blocks are > contained within OS pages? This comment comes from pg_get_shmem_allocations_numa() and I agree that it could be misleading: it all depends what the OS and block sizes actually are: fixed in v5 attached where the wording is almost the same as in pg_buffercache_numa_pages(). Also I think that it is not correct in pg_get_shmem_allocations_numa(), I think that it should be something like proposed in [1]. [1]: https://www.postgresql.org/message-id/aH4DDhdiG9Gi0rG7%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: