Re: Manipulating complex types as non-contiguous structures in-memory - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Manipulating complex types as non-contiguous structures in-memory
Date
Msg-id 20150514010609.GC9584@alap3.anarazel.de
Whole thread Raw
In response to Re: Manipulating complex types as non-contiguous structures in-memory  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Manipulating complex types as non-contiguous structures in-memory  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2015-05-13 21:01:43 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2015-05-13 20:48:51 -0400, Tom Lane wrote:
> >> I still think that going back to defining the second byte as the size
> >> would be better.  Fortunately, since this is only a matter of in-memory
> >> representations, we aren't committed to any particular answer.
> 
> > Requiring sizes to be different still strikes me as a disaster. Or is
> > that not what you're proposing?
> 
> It is, but why would it be a disaster?  We could add StaticAsserts
> verifying that the sizes actually are different.  I doubt that the pad
> space itself could amount to any issue performance-wise, since it would
> only ever exist in transient in-memory tuples, and even that only seldom.

The sizes would be platform dependant. It's also just incredibly ugly to
have to add pad bytes to structures so we can disambiguate them.

Anyway, I think we can live with your & or my proposed additional branch
for now. I can't see either variant being a relevant performance
bottleneck anytime soon.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Manipulating complex types as non-contiguous structures in-memory
Next
From: Tom Lane
Date:
Subject: Re: Manipulating complex types as non-contiguous structures in-memory