Re: [HACKERS] Terrible performance on wide selects

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: [HACKERS] Terrible performance on wide selects
Дата
Msg-id
25701.1043333210@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Re: [HACKERS] Terrible performance on wide selects "Dann Corbit" <DCorbit@connx.com>
Re: [HACKERS] Terrible performance on wide selects Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] Terrible performance on wide selects Tom Lane <tgl@sss.pgh.pa.us>
Hannu Krosing  writes:
> as  tuple (int,int,int,varchar,varchar)
> which is currently stored as
> (intdata1, intdata2, intdata3, (len4, vardata4), (len5,vardata5))
> should be rewritten on storage to
> (ptr4,ptr5),(intdata1, intdata2, intdata3, vardata4,vardata5)

I do not see that this buys anything at all.  heap_getattr still has to
make essentially the same calculation as before to determine column
locations, namely adding up column widths.  All you've done is move the
data that it has to fetch to make the calculation.  If anything, this
will be slower not faster, because now heap_getattr has to keep track
of two positions not one --- not just the next column offset, but also
the index of the next "ptr" to use.  In the existing method it only
needs the column offset, because that's exactly where it can pick up
the next length from.

But the really serious objection is that the datatype functions that
access the data would now also need to be passed two pointers, since
after all they would like to know the length too.  That breaks APIs
far and wide :-(

			regards, tom lane
В списке pgsql-performance по дате отправления
От: Tom Lane
Дата:
От: Tom Lane
Дата:
FAQ