From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dann Corbit <DCorbit(at)connx(dot)com>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, pgsql-performance(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Terrible performance on wide selects |
Date: | 2003-01-23 10:41:48 |
Message-ID: | 1043318508.2347.39.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers 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(at)tm(dot)ee>
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Kalchev | 2003-01-23 10:44:04 | Re: Terrible performance on wide selects |
Previous Message | Hannu Krosing | 2003-01-23 10:30:48 | Re: Terrible performance on wide selects |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Kalchev | 2003-01-23 10:44:04 | Re: Terrible performance on wide selects |
Previous Message | Hannu Krosing | 2003-01-23 10:30:48 | Re: Terrible performance on wide selects |