Hi, On 2019-01-09 14:44:24 -0500, Tom Lane wrote: > I wrote: > > Also, I fail to understand why fmgr_builtin_oid_index has 10000 entries > > anyway. We could easily have fmgrtab.c expose the last actually assigned > > builtin function OID (presently 6121) and make the index array only > > that big, which just about eliminates the space advantage completely. > > Concretely, like the attached.
Seems like a good improvement. > We could make the index table still smaller if we wanted to reassign > a couple dozen high-numbered functions down to lower OIDs, but I dunno > if it's worth the trouble. It certainly isn't from a performance > standpoint, because those unused entry ranges will never be touched > in normal usage; but it'd make the server executable a couple KB smaller. Probably indeed not worth it. I'm not 100% convinced on the performance POV, but in contrast to the earlier binary search either approach is fast enough that it probably hard to measure any difference. > diff --git a/src/backend/utils/fmgr/fmgindex b41649f..506eeef 100644 > --- a/src/backend/utils/fmgr/fmgr.c > +++ b/src/backend/utils/fmgr/fmgr.c > @@ -75,12 +75,12 @@ fmgr_isbuiltin(Oid id) > uint16 index; > > /* fast lookup only possible if original oid still assigned */ > - if (id >= FirstGenbkiObjectId) > + if (id > fmgr_last_builtin_oid) > return NULL; An extern reference here will make the code a bit less efficient, but it's probably not worth generating a header with a define for it instead... Greetings, Andres Freund
