Re: GISTSTATE is too large

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GISTSTATE is too large
Date: 2021-04-26 05:11:13
Message-ID: 842D9971-3AA7-4D00-AB3B-77E5BA922FAF@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 26 апр. 2021 г., в 03:20, Andres Freund <andres(at)anarazel(dot)de> написал(а):
>
> So the basic GISTSTATE is 14kB large. And all the information needed to
> call support functions for one attribute is spaced so far appart that
> it's guaranteed to be on different cachelines and to be very unlikely to
> be prefetched by the hardware prefetcher.
>
> It seems pretty clear that this should be changed to be something more
> like
>
> ...
>
> with initGISTstate allocating based on
> IndexRelationGetNumberOfKeyAttributes() instead of using a constant.
>
> And then subsequently change GIST_COL_STATE to embed the
> FunctionCallInfo, rather than initializiing them on the stack for every
> call.
Yes, this makes sense. Also, it's viable to reorder fields to group scan and insert routines together, currently they are interlaced.
Or maybe we could even split state into insert state and scan state.

> I'm not planning on doing this work, but I thought it's sensible to send
> to the list anyway.

Thanks for idea, I would give it a shot this summer, unless someone else will take it earlier.
BTW, It would make sense to avoid penalty call at all: there are many GiST-based access methods that want to see all items together to choose insertion subtree (e.g. R*-tree and RR-tree). Calling penalty function for each tuple on page often is not a good idea at all.

Thanks!

Best regards, Andrey Borodin.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey V. Lepikhov 2021-04-26 06:01:12 Re: Asynchronous Append on postgres_fdw nodes.
Previous Message Amit Kapila 2021-04-26 05:04:31 Re: Forget close an open relation in ReorderBufferProcessTXN()