On Mon, Sep 3, 2018 at 9:09 PM Andrey Borodin <x4...@yandex-team.ru> wrote: > > 3 сент. 2018 г., в 20:16, Alexander Korotkov <a.korot...@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 tested that. > 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