| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Artur Zakirov <zaartur(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Re: type cache cleanup improvements |
| Date: | 2024-10-21 05:40:14 |
| Message-ID: | f8d8d179-ad31-4b46-aaef-3916be8bc8af@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 21/10/2024 06:32, Dagfinn Ilmari Mannsåker wrote:
> Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
>
>> +static Oid *in_progress_list;
>> +static int in_progress_list_len;
>> +static int in_progress_list_maxlen;
>
> Is there any particular reason not to use pg_list.h for this?
Sure. The type cache lookup has to be as much optimal as possible.
Using an array and relating sequential access to it, we avoid memory
allocations and deallocations 99.9% of the time. Also, quick access to
the single element (which we will have in real life almost all of the
time) is much faster than employing list machinery.
--
regards, Andrei Lepikhov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2024-10-21 05:50:44 | Re: simplify regular expression locale global variables |
| Previous Message | Andrei Lepikhov | 2024-10-21 05:36:04 | Re: type cache cleanup improvements |