Hi, On 2019-04-17 19:22:08 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2019-04-17 18:57:00 -0400, Tom Lane wrote: > >> What on God's green earth are these functions doing in > >> src/include/catalog/index.h? > > > I'm happy to move them elsewhere, but I'm not sure there's really a good > > location. I guess we could move them to itemptr.h - but they're not > > really something particularly generally usable. > > I don't have a better idea than that either, but I sure feel that they > don't belong in index.h. Is it worth inventing a whole new header > for these? If we stick 'em in itemptr.h, they'll be getting compiled > by a whole lot of files :-(
itemptr_utils.h? I don't have an opinion on whether we ought to move them in v12 or v13. Don't think there's a beta1 pressure. > As for the general usability argument, I'm not sure --- as we start > to look at alternate AMs, we might have more use for them. When I first > saw the functions, I thought maybe they were part of sort acceleration > for TIDs; evidently they're not (yet), but that seems like another > possible use-case. We ought to use them in a few more places. E.g. nodeTidscan.c's sorting would likely be faster if we used something of that kind. And, what'd probably substantially beneficial, for the junk ctid columns - where they're currently IIRC transported as a by-ref datum, even on 64bit machines. Mildly related: Is there a reason we don't optimize fixed-length !byval datum copies for typlen < sizeof(Datum) to something better than a full palloc? I guess it'd be somewhat of a breaking change? Greetings, Andres Freund