From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Artur Zakirov <zaartur(at)gmail(dot)com>, Alexander Lakhin <exclusion(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-22 17:33:24 |
Message-ID: | CAPpHfdv=WVCbzdpoTxvXzUZZEqu_pDk2YZBnEGpUCrzuHxPN6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 22, 2024 at 6:10 PM Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> wrote:
> On Tue, 22 Oct 2024 at 11:34, Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>>
>> On Mon, Oct 21, 2024 at 2:30 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>> >
>> > On Mon, Oct 21, 2024 at 1:16 PM Dagfinn Ilmari Mannsåker
>> > <ilmari(at)ilmari(dot)org> wrote:
>> > > Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
>> > >
>> > > > On Mon, Oct 21, 2024 at 8:40 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>> > > >>
>> > > >> 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.
>> > >
>> > > Lists are actually dynamically resized arrays these days (see commit
>> > > 1cff1b95ab6ddae32faa3efe0d95a820dbfdc164), not linked lists, so
>> > > accessing arbitrary elements is O(1), not O(n). Just like this patch,
>> > > the size is doubled (starting at 16) whenever array is full.
>> > >
>> > > > +1,
>> > > > List with zero elements has to be NIL. That means continuous
>> > > > allocations/deallocations.
>> > >
>> > > This however is a valid point (unless we keep a dummy zeroth element to
>> > > avoid it, which is even uglier than open-coding the array extension
>> > > logic), so objection withdrawn.
>> >
>> > OK, thank you!
>> >
>> > The attached revision fixes EXTRA_INSTALL in
>> > src/test/modules/typcache/Makefile. Spotted off-list by Arthur
>> > Zakirov.
>>
>> I've re-checked that regression tests pass with
>> -DCLOBBER_CACHE_ALWAYS. Also did some grammar corrections for
>> comments and commit message. I'm going to push this if no objections.
>
> Thank you for working on this patch!
> Looked through the patchset once more.
>
> Patch 0001 (minor): "in the last" -> "after everything else" or "after other TypeCacheEntry contents"
>
> Patch 0002 looks ready to me.
Thank you, Pavel! 0001 revised according to your suggestion.
------
Regards,
Alexander Korotkov
Supabase
Attachment | Content-Type | Size |
---|---|---|
v19-0001-Update-header-comment-for-lookup_type_cache.patch | application/octet-stream | 1.6 KB |
v19-0002-Avoid-looping-over-all-type-cache-entries-in-Typ.patch | application/octet-stream | 24.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2024-10-22 17:41:09 | Re: Inconsistent use of relpages = -1 |
Previous Message | Maxim Orlov | 2024-10-22 16:33:58 | Re: POC: make mxidoff 64 bits |