Re: A strange GiST error message or fillfactor of GiST build - Mailing list pgsql-hackers

At Mon, 3 Sep 2018 23:05:23 +0300, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote in
<CAPpHfdsruk4eEkVTUFTHV7tg9RXQHqvOvBY18p-5pBNqp+PU6w@mail.gmail.com>
> 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.

I agree that fillfactor should be ignored in certain cases
(inserting the first tuple into empty pages or something like
that). Even though GiST doesn't need fillfactor at all, it is
defined independently from AM instances and it gives some
(undocumented) convenient on testing even on GiST.

So, does the following makes sense?

- Preserve fillfactor on GiST but set its default to 100%.

- Ignore fillfactor iff the first tuple for the new page fail
  with it but succeed without it.

- Modify GiST internal routines to bring around GISTInsertState
  so that they can see fillfactor or any other parameters without
  further modification.

  https://www.postgresql.org/message-id/20180830.144209.208080135.horiguchi.kyotaro@lab.ntt.co.jp

# A storm (literally) is coming behind...

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center