Re: [HACKERS] Terrible performance on wide selects - Mailing list pgsql-performance

From Hannu Krosing
Subject Re: [HACKERS] Terrible performance on wide selects
Date
Msg-id 1043318508.2347.39.camel@localhost.localdomain
Whole thread Raw
In response to Re: [HACKERS] Terrible performance on wide selects  (Hannu Krosing <hannu@tm.ee>)
Responses Re: [HACKERS] Terrible performance on wide selects  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] Terrible performance on wide selects
Next
From: Daniel Kalchev
Date:
Subject: Re: [HACKERS] Terrible performance on wide selects