Re: Manipulating complex types as non-contiguous structures in-memory

Without having read the patch, I think this is great. I've been wishing
for something like this while working on my variant data type.

Are there any cases where we would want to use this on a non-variant?
Perhaps types where we're paying an alignment penalty?

On 2/10/15 3:00 PM, Stephen Frost wrote:
>> >BTW, I'm not all that thrilled with the "deserialized object" terminology.
>> >I found myself repeatedly tripping up on which form was serialized and
>> >which de-. If anyone's got a better naming idea I'm willing to adopt it.
> Unfortunately, nothing comes to mind. Serialization is, at least, a
> pretty well understood concept and so the naming will likely make sense
> to newcomers, even if it's difficult to keep track of which is
> serialized and which is deserialized.

Apologies if I'm just dense, but what's the confusion? Is it what a
serialized datum means in this context? (de)serialized seems like a
perfectly logical name to me...

>> >I'm not sure exactly how to push this forward. I would not want to
>> >commit it without converting a significant number of array functions to
>> >understand about deserialized inputs, and by the time I've finished that
>> >work it's likely to be too late for 9.5. OTOH I'm sure that the PostGIS
>> >folk would love to have this infrastructure in 9.5 not 9.6 so they could
>> >make a start on fixing their issues. (Further down the pike, I'd plan to
>> >look at adapting composite-type operations, JSONB, etc, to make use of
>> >this approach, but that certainly isn't happening for 9.5.)
>> >
>> >Thoughts, advice, better ideas?
> I'm not really a big fan of putting an infrastructure out there for
> modules to use that we don't use ourselves (particularly when it's clear
> that there are places where we could/should be). On the other hand,
> this doesn't impact on-disk format and therefore I'm less worried that
> we'll end up with a release-critical issue when we're getting ready to
> put 9.5 out there.
>
> So, I'm on the fence about it. I'd love to see all of this in 9.5 with
> the array functions converted, but I don't think it'd be horrible if
> only a subset had been done in time for 9.5. The others aren't going to
> go anywhere and will still work. I do think it'd be better to have at
> least some core users of this new infrastructure rather than just
> putting it out there for modules to use but I agree it'd be a bit grotty
> to have only some of the array functions converted.

I think the solution here is to have people other than Tom do the
gruntwork of applying this to the remaining array code. My thought is
that if Tom shows how to do this correctly in a rather complex case (ie,
where you need to worry about primary vs secondary), then less
experienced hackers should be able to take the ball and run with it.

Maybe we won't get complete array coverage, but I think any performance
gains here are a win. And really, don't we just need enough usage so the
buildfarm will tell us if we accidentally break something?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com