Re: [HACKERS] Terrible performance on wide selects

Added to TODO:

* Cache last known per-tuple offsets to speed long tuple access

---------------------------------------------------------------------------

Tom Lane wrote:
> Hannu Krosing <hannu(at)tm(dot)ee> 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
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073