Re: [HACKERS] Terrible performance on wide selects
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] Terrible performance on wide selects |
Дата | |
Msg-id | 1043318508.2347.39.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: [HACKERS] Terrible performance on wide selects (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: [HACKERS] Terrible performance on wide selects
|
Список | pgsql-performance |
Hannu Krosing kirjutas N, 23.01.2003 kell 12:11: > make the pointer array incrementally for O(N) performance: > > 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. One has to watch the NULL bitmap on fist pass anyway. > so the first call to get col[5] will fill first 5 positions in the array > save said nr 5 and then access tuple[ptrarray[5]] > > next call to get col[75] will start form col[5] and fill up to col[75] > > next call to col[76] will start form col[75] and fill up to col[76] > > next call to col[60] will just get tuple[ptrarray[60]] > > the above description assumes 1-based non-C arrays ;) -- Hannu Krosing <hannu@tm.ee>
В списке pgsql-performance по дате отправления: