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

At Tue, 4 Sep 2018 13:05:55 +0300, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote in <CAPpHfdsJwptVsRnBtTdtj+G+gTTfSrqdH1uwLNkvQ-72A9scgw(at)mail(dot)gmail(dot)com>
> On Tue, Sep 4, 2018 at 12:16 PM Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> > 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
>
> What exactly do you mean? Yes, fillfactor is defined in StdRdOptions
> struct, which is shared across many access methods. But some of them
> uses fillfactor, while others don't. For instance, GIN and BRIN don't
> support fillfactor at all.

Yes. It was with the intent of keeping Andrey's use case. So I
proposed that just disabling it rather than removing the code at
all.

> > and it gives some
> > (undocumented) convenient on testing even on GiST.
>
> Do you keep in the mind some particular use cases? If so, could you
> please share them. It would let me and others understand what
> behavior we need to preserve and why.

I misunderstood the consensus here, I myself don't have a proper
one. The consensus here is:

fillfactor is useless for GiST.
We don't preserve it for Andrey's use case.
No one is objecting to ignoring it here.

Is it right?

Well, I propose the first attached instaed. It just removes
fillfactor handling from GiST.

Apart from the fillfactor removal, we have an internal error for
rootsplit failure caused by too-long tuples, but this should be a
user error message like gistSplit. (index row size %zu exeeds..)

=# create table y as select cube(array(SELECT random() as a FROM generate_series(1,600))) from generate_series(1,1e3,1);
=# create index on y using gist(cube);
ERROR: failed to add item to index page in "y_cube_idx"

The attached second patch changes the message in the case.

ERROR: size of 2 index rows (9640 bytes) exceeds maximum 8152 of the root page for the index "y_cube_idx"

This is one of my first motivation here but now this might be
another issue.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center