From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Summary function for pg_buffercache |
Date: | 2022-09-20 09:45:24 |
Message-ID: | CAJ7c6TP16NnAY5VD9o2kFtWiz4OU2dXdSd7KwPEVcP40nb=cAg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
v7-0001-Added-pg_buffercache_summary-function.patch | application/octet-stream | 11.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-09-20 09:59:04 | Re: ICU for global collation |
Previous Message | Zhang Mingli | 2022-09-20 09:37:32 | Re: Add 64-bit XIDs into PostgreSQL 15 |