Re: Summary function for pg_buffercache - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: Summary function for pg_buffercache
Date
Msg-id CAJ7c6TP16NnAY5VD9o2kFtWiz4OU2dXdSd7KwPEVcP40nb=cAg@mail.gmail.com
Whole thread Raw
In response to Re: Summary function for pg_buffercache  (Melih Mutlu <m.melihmutlu@gmail.com>)
Responses Re: Summary function for pg_buffercache
Re: Summary function for pg_buffercache
List pgsql-hackers
Hi Melih,

> I changed these names and updated the patch.

Thanks for the updated patch!

> Aleksander, do you still think the average usagecount is a bit useless? Or does it make sense to you to keep it like
this?

I don't mind keeping the average.

> I'm not sure how to avoid any undefined behaviour without locks though.
> Even with locks, performance is much better. But is it good enough for production?

Potentially you could avoid taking locks by utilizing atomic
operations and lock-free algorithms. But these algorithms are
typically error-prone and not always produce a faster code than the
lock-based ones. I'm pretty confident this is out of scope of this
particular patch.

The patch v6 had several defacts:

* Trailing whitespaces (can be checked by applying the patch with `git am`)
* Wrong code formatting (can be fixed with pgindent)
* Several empty lines were removed which is not related to the
proposed change (can be seen with `git diff`)
* An unlikely division by zero if buffers_used = 0
* Missing part of the commit message added in v4

Here is a corrected patch v7. To me it seems to be in pretty good
shape, unless cfbot and/or other hackers will report any issues.

-- 
Best regards,
Aleksander Alekseev

Attachment

pgsql-hackers by date:

Previous
From: Zhang Mingli
Date:
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
Next
From: Peter Eisentraut
Date:
Subject: Re: ICU for global collation