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
signature.asc
Description: PGP signature