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 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Added to TODO: * Cache last known per-tuple offsets to speed long tuple access --------------------------------------------------------------------------- Tom Lane wrote: > Hannu Krosing <hannu@tm.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@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 по дате отправления: