Re: itemptr_encode/itemptr_decode

Hi,

On 2019-04-17 19:22:08 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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