Re: pg_stat_get_backend_subxact() and backend IDs? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_stat_get_backend_subxact() and backend IDs?
Date
Msg-id ZOv+MHonWVgW/bpf@paquier.xyz
Whole thread Raw
In response to Re: pg_stat_get_backend_subxact() and backend IDs?  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Responses Re: pg_stat_get_backend_subxact() and backend IDs?
List pgsql-hackers
On Fri, Aug 25, 2023 at 10:56:14PM +0000, Imseih (AWS), Sami wrote:
> > Here is a new version of the patch that avoids changing the names of the
> > existing functions. I'm not thrilled about the name
> > (pgstat_fetch_stat_local_beentry_by_backend_id), so I am open to
> > suggestions. In any case, I'd like to rename all three of the>
> > pgstat_fetch_stat_* functions in v17.
>
> Thanks for the updated patch.
>
> I reviewed/tested the latest version and I don't have any more comments.

FWIW, I find the new routine introduced by this patch rather
confusing.  pgstat_fetch_stat_local_beentry() and
pgstat_fetch_stat_local_beentry_by_backend_id() use the same
argument name for a BackendId or an int.  This is not entirely the
fault of this patch as pg_stat_get_backend_subxact() itself is
confused about "beid" being a uint32 or a BackendId.  However, I think
that this makes much harder to figure out that
pgstat_fetch_stat_local_beentry() is only here because it is cheaper
to do sequential scan of all the local beentries rather than a
bsearch() for all its callers, while
pgstat_fetch_stat_local_beentry_by_backend_id() is here because we
want to retrieve the local beentry matching with the *backend ID* with
the binary search().

I understand that this is not a fantastic naming, but renaming
pgstat_fetch_stat_local_beentry() to something like
pgstat_fetch_stat_local_beentry_by_{index|position}_id() would make
the difference much easier to grasp, and we should avoid the use of
"beid" when we refer to the *position/index ID* in
localBackendStatusTable, because it is not a BackendId at all, just a
position in the local array.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Logger process and "LOG: could not close client or listen socket: Bad file descriptor"
Next
From: Yugo NAGATA
Date:
Subject: Re: Incremental View Maintenance, take 2