Hannu Krosing <[EMAIL PROTECTED]> writes:
>> i.e. for tuple with 100 cols, allocate an array of 100 pointers, plus
>> keep count of how many are actually valid,
> Additionally, this should also make repeted determining of NULL fields
> faster - just put a NULL-pointer in and voila - no more bit-shifting and
> AND-ing to find out if the field is null.
Right, the output of the operation would be a pair of arrays: Datum
values and is-null flags. (NULL pointers don't work for pass-by-value
datatypes.)
I like the idea of keeping track of a last-known-column position and
incrementally extending that as needed.
I think the way to manage this is to add the overhead data (the output
arrays and last-column state) to TupleTableSlots. Then we'd have
a routine similar to heap_getattr except that it takes a TupleTableSlot
and makes use of the extra state data. The infrastructure to manage
the state data is already in place: for example, ExecStoreTuple would
reset the last-known-column to 0, ExecSetSlotDescriptor would be
responsible for allocating the output arrays using the natts value from
the provided tupdesc, etc.
This wouldn't help for accesses that are not in the context of a slot,
but certainly all the ones from ExecEvalVar are. The executor always
works with tuples stored in slots, so I think we could fix all the
high-traffic cases this way.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
