Hi,
Thanks! As the most recent changes are only docs and tests, I did not
try out v6 anymore, but just checked the CI result; all green.
I've set the status to Ready for Committer.
Kind regards,
Mircea Cadariu
Hi,
On Thu, Jul 24, 2025 at 10:30:06PM +0800, Mircea Cadariu wrote:
> I tried v5 and it returns the expected results on my
> laptop, same as before.
Thanks for the review and testing.
>
> Just two further remarks for your consideration.
>
> > +
> > + number of OS memory page for th
Hi,
Thanks for the update! I tried v5 and it returns the expected results on
my laptop, same as before.
Just two further remarks for your consideration.
+
+ number of OS memory page for this buffer
+
Let's capitalize the first letter here.
+-- Check that the functions
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)
> > +
Hi,
Thanks for the prompt reply!
On 09/07/2025 08:37, Bertrand Drouvot wrote:
Yeah, I tried to avoid code duplication for the "os pages" related stuff in
v1. I can check if more can be done (outside of the "os pages" related stuff).
Might be done in a dedicated patch though, I mean I don't thi
Hi,
On Tue, Jul 08, 2025 at 02:47:34PM +, Mircea Cadariu wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi Bertrand,
Just tried out your patch, nice work, thought
Hi,
On Wed, Jul 02, 2025 at 06:39:25AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Tue, Jul 01, 2025 at 07:46:30PM +0200, Tomas Vondra wrote:
> > On 7/1/25 19:20, Bertrand Drouvot wrote:
> > > Now it's just a matter of extracting the necessary pieces from
> > > pg_buffercache_numa_pages()
> > >
Hi,
On Tue, Jul 01, 2025 at 07:46:30PM +0200, Tomas Vondra wrote:
> On 7/1/25 19:20, Bertrand Drouvot wrote:
> > Now it's just a matter of extracting the necessary pieces from
> > pg_buffercache_numa_pages()
> > so that:
> >
> > * the new view could make use of it
> > * the maintenance burden sh
On 7/1/25 19:20, Bertrand Drouvot wrote:
> Hi,
>
> On Tue, Jul 01, 2025 at 06:45:37PM +0200, Tomas Vondra wrote:
>> On 7/1/25 18:34, Bertrand Drouvot wrote:
>>
>> But isn't the _numa view good enough for this? Sure, you need NUMA
>> support for it, and it may take a fair amount of time, but how of
Hi,
On Tue, Jul 01, 2025 at 06:45:37PM +0200, Tomas Vondra wrote:
> On 7/1/25 18:34, Bertrand Drouvot wrote:
>
> But isn't the _numa view good enough for this? Sure, you need NUMA
> support for it, and it may take a fair amount of time, but how often you
> need to do such queries?
Not that often
On 7/1/25 18:34, Bertrand Drouvot wrote:
> Hi,
>
> On Tue, Jul 01, 2025 at 04:31:01PM +0200, Tomas Vondra wrote:
>> On 7/1/25 15:45, Bertrand Drouvot wrote:
>>
>> I took a quick look on this,
>
> Thanks for looking at it!
>
>> and I doubt we want to change the schema of
>> pg_buffercache like th
Hi,
On Tue, Jul 01, 2025 at 04:31:01PM +0200, Tomas Vondra wrote:
> On 7/1/25 15:45, Bertrand Drouvot wrote:
>
> I took a quick look on this,
Thanks for looking at it!
> and I doubt we want to change the schema of
> pg_buffercache like this. Adding columns is fine, but it seems rather
> wrong t
d
> a function to avoid some code duplication between pg_buffercache_pages() and
> pg_buffercache_numa_pages().
>
> So, PFA:
>
> 0001 - Introduce GET_MAX_BUFFER_ENTRIES and get_buffer_page_boundaries
>
> Those new macro and function are extracted from pg_buffercache_numa_pages()
>
T_MAX_BUFFER_ENTRIES and get_buffer_page_boundaries
Those new macro and function are extracted from pg_buffercache_numa_pages() and
pg_buffercache_numa_pages() makes use of them.
0002 - Add os_page_num to pg_buffercache
Making use of the new macro and function from 0001.
As it's for v19, al
Hi,
On Thu, Apr 10, 2025 at 09:58:18AM -0500, Nathan Bossart wrote:
> On Thu, Apr 10, 2025 at 03:35:24PM +0200, Tomas Vondra wrote:
> > This seems like a good idea in principle, but at this point it has to
> > wait for PG19. Please add it to the July commitfest.
>
> +1. From a glance, this seems
On 4/10/25 15:17, Bertrand Drouvot wrote:
> Hi hackers,
>
> I was doing some more tests around ba2a3c2302f (pg_buffercache_numa) and
> thought that seeing how buffers are spread across multiple OS pages (if that's
> the case) thanks to the os_page_num field is good information to have.
>
> The
On Thu, Apr 10, 2025 at 03:35:24PM +0200, Tomas Vondra wrote:
> This seems like a good idea in principle, but at this point it has to
> wait for PG19. Please add it to the July commitfest.
+1. From a glance, this seems to fall in the "new feature" bucket and
should likely wait for v19.
--
natha
s Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From 1d3516efd6ee1c18a82f56b87c5afc3d54fb62cf Mon Sep 17 00:00:00 2001
From: Bertrand Drouvot
Date: Thu, 10 Apr 2025 05:49:45 +
Subject: [PATCH v1] Add os_page_num to pg_buffercache
ba2a3c2302f added a way to check if
19 matches
Mail list logo
