Re: Terrible performance on wide selects

Поиск
Список
Период
Сортировка
Искать
От
Bruce Momjian
Тема
Re: Terrible performance on wide selects
Дата
Msg-id
200302141311.h1EDBb020716@candle.pha.pa.us
Ответ на
Список
Дерево обсуждения
Re: Terrible performance on wide selects "Dann Corbit" <DCorbit@connx.com>
Re: Terrible performance on wide selects Tom Lane <tgl@sss.pgh.pa.us>
Re: Terrible performance on wide selects Hannu Krosing <hannu@tm.ee>
Re: Terrible performance on wide selects Hannu Krosing <hannu@tm.ee>
Re: Terrible performance on wide selects Tom Lane <tgl@sss.pgh.pa.us>
Re: Terrible performance on wide selects Bruce Momjian <pgman@candle.pha.pa.us>

Added to TODO:

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


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

Tom Lane wrote:
> Hannu Krosing  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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
В списке pgsql-hackers по дате отправления
От: Oliver Elphick
Дата:
От: Bruce Momjian
Дата:
FAQ