Re: GiST "choose subtree" support function to inline penalty

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: GiST "choose subtree" support function to inline penalty
Дата
Msg-id CAPpHfdssv2i7CXTBfiyR6=_A3tp19+iLo-pkkfD6Guzs2-tvEw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GiST "choose subtree" support function to inline penalty  (Andrey Borodin <x4mmm@yandex-team.ru>)
Список pgsql-hackers
On Mon, Jun 24, 2019 at 2:31 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> 24 июня 2019 г., в 15:08, Darafei Komяpa Praliaskouski <me@komzpa.net> написал(а):
>
> I'm looking at PostGIS geometry GiST index build times and try to optimize withing the current GiST framework. The function that shows a lot on my flame graphs is penalty.
>
> I spent weekend rewriting PostGIS penalty to be as fast as possible.
> (FYI https://github.com/postgis/postgis/pull/425/files)
>
> However I cannot get any meaningfully faster build time. Even when I strip it to "just return edge extension" index build time is the same.
>
> Is there a way to inline the penalty into above "choose subtree" loop somehow? That would also let us stop bit-fiddling floats to simulate a more complex choosing scheme.

Maybe we could just add new opclass function for choosing subtree?

+1,
This sounds reasonable.  Authors of existing GiST opclasses wouldn't have trouble to keep compatible with new PostgreSQL versions.

I see one more use case for "choose subtree" instead "penalty".  When R*-tree chooses subtree, it considers to only extension of selected bounding box, but also overlap increase of bounding boxes.  This strategy should have a positive effect of tree quality, besides I never seen it has been measured separately.  It probably kind of possible to implement using "penalty" method assuming you have reference to the page in GISTENTRY.  But that doesn't seems a correct way to use the GiST interface.  Additionally, you don't know the attribute number to get the correct key in multicolumn indexes.  Having "choose subtree" method will make it possible to implement this strategy in correct way.  However, this use case is kind of opposite to Darafei's one, because it should make choosing subtree slower (but better).

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: GiST VACUUM