Re: A strange GiST error message or fillfactor of GiST build

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: A strange GiST error message or fillfactor of GiST build
Дата
Msg-id 20180904.181610.116195527.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: A strange GiST error message or fillfactor of GiST build  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: A strange GiST error message or fillfactor of GiST build  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Список 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





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

Предыдущее
От: Chi Gao
Дата:
Сообщение: Enable using IS NOT DISTINCT FROM in hash and merge joins
Следующее
От: Sandeep Thakkar
Дата:
Сообщение: Re: [HACKERS] git down