Re: Rethinking TupleTableSlot deforming

On 7/22/16 1:35 PM, Andres Freund wrote:
> Sure, it's intentional. But not working that well. The problem is that
> very often we actually don't ever access the preceding
> columns. Sometimes that knowledge would let us skip directly to the
> interesting column(s) (fixed width, no nulls columns preceding). But
> even if not, just the fact that we don't have to copy the column data
> for columns never accessed can make for a *significant* speed bump. For
> !varlena datatypes we don't ever have to access the data, just the NULL
> bitmap. And for varlena ones, we just need to check the varlena header
> for the width, not make variable width copy.
>
> So what I'm saying is, that we should pre-compute the set of columns
> we're interested in, and deform just those, but still in bulk.

Another option would be to remember the tuple offsets (NOT attcacheoff)
that have been computed as well as whether a varlena attribute has
actually been deformed. That eliminates the need to pre-declare what
attributes you're allowed to reference.

Somewhat related, it's occurred to me that it would be nice if expanded
objects supported partial expansion. IE: if we converted JSONB to be an
expanded object, you would not want to proactively expand every value in
a JSON object, because each of those values could itself be very large.
Obviously most of the work there would be up to the type that was
handling the details of the expansion, but IIRC there's some additional
support that would be needed in expanded objects themselves.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461