On Mon, Sep 3, 2018 at 9:09 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> > 3 сент. 2018 г., в 20:16, Alexander Korotkov <a.korotkov@postgrespro.ru> написал(а):
> > That's a good idea. Especially if we take into account that
> > fillfactor is not a forever bad idea for GIST, it just doesn't look
> > reasonable for current building algorithm. So, we can decide to
> > ignore it, but if we would switch to different GiST building
> > algorithm, which can pack pages tightly, we can take fillfactor into
> > account again.
> BTW, I think that build algorithm may be provided by opclass.
I don't think that providing the whole building algorithm by opclass
is a good idea. But we could rather make opclass provide some
essential routines for build algorithm. For instance, we may
implement sorting-based build algorithm for GiST (like one we have for
B-tree). It wouldn't work for all the opclass'es, but definitely
should work for some of them. Geometrical opclass'es may sort values
by some kind of space-filling curve. In this case, opclass can define
a comparison function.
> > I think I need to prove my position about GiST fillfactor with some
> > experiments first, and then propose a patch.
> FWIW fillfactor can be a cheap emulator for intrapage indexing, when you have like a lot of RAM. Though I didn't
testedthat.
> Also I believe proper intrapage indexing is better :)
It might be somewhat useful side effect for developers. But it's
definitely doesn't look like a feature we should encourage users to
use.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
