Hi Haibo,
Thanks for your review!
On Mon, Mar 16, 2026 at 9:21 PM Haibo Yan <tristan.yim@gmail.com> wrote:
> Could this use RelFileLocator plus ForkNumber instead of open-coding BufferRelStatsKey? That seems closer to existing
PostgreSQLabstractions for physical relation identity.
Yes, that was noted by other reviewers as well, and makes sense.
> I wonder whether pg_buffercache_relation_stats() is the best name here. The function is really aggregating by
relationfile identity plus fork, and it is producing a summary of the current buffer contents rather than what many
readersmight assume from “relation stats”. Would something with summary be clearer than stats?
Per the most recent feedback, I'll rename this to
"pg_buffercache_relations" for now.
> Why are OUT relforknumber and OUT relfilenode exposed as int2 and oid respectively? Internally these are represented
asForkNumber and RelFileNumber, so I wonder whether the SQL interface should reflect that more clearly, or at least
whetherthe current choice should be explained.
This is consistent with how pg_buffercache_pages represents them - I
think those are the correct mappings of the int ForkNumber (which we
know to be small in practice) and RelFileNumber is a typedef of Oid.
> The comment says, “Hash key for pg_buffercache_relation_stats — groups by relation identity”, but that seems
imprecise.It is really grouping by relfilenode plus fork, i.e. physical relation-file identity rather than relation
identityin a more logical sense.
Good point. I'll adapt this to "groups by relation file" for now.
> Is PARALLEL SAFE actually desirable here, as opposed to merely technically safe? A parallel query could cause
multipleworkers to perform full shared-buffer scans independently, which does not seem obviously desirable for this
kindof diagnostic function.
I see your point, but I don't think a parallel plan would happen in
practice when just the function is being queried. Since other
pg_buffercache functions are also PARALLEL SAFE, I'll keep this as is
for now - if we want to adjust it we should be consistent I think.
Thanks,
Lukas
--
Lukas Fittl
