Re: Terrible performance on wide selects

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>

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-performance by date

  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