Re: itemptr_encode/itemptr_decode - Mailing list pgsql-hackers

From Andres Freund
Subject Re: itemptr_encode/itemptr_decode
Date
Msg-id 20190518013159.af3msaaguwiq3rda@alap3.anarazel.de
Whole thread Raw
In response to Re: itemptr_encode/itemptr_decode  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

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



pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: Passing CopyMultiInsertInfo structure to CopyMultiInsertInfoNextFreeSlot()
Next
From: Tom Lane
Date:
Subject: Re: Calling PrepareTempTablespaces in BufFileCreateTemp