Re: type cache cleanup improvements - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: type cache cleanup improvements
Date
Msg-id CAPpHfdvMVevMxAob4Yav9LyW2a4nrWqxUVQ8K1=Hs7EjOPQk1w@mail.gmail.com
Whole thread Raw
In response to Re: type cache cleanup improvements  (Andrei Lepikhov <lepihov@gmail.com>)
List pgsql-hackers
On Mon, Oct 21, 2024 at 8:40 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
>
> On 21/10/2024 06:32, Dagfinn Ilmari Mannsåker wrote:
> > Alexander Korotkov <aekorotkov@gmail.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.

+1,
List with zero elements has to be NIL.  That means continuous
allocations/deallocations.

------
Regards,
Alexander Korotkov
Supabase



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: type cache cleanup improvements
Next
From: Tender Wang
Date:
Subject: Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails