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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to