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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A strange GiST error message or fillfactor of GiST build
Date: 2018-09-01 15:02:51
Message-ID: CA+Tgmob8nqkeK9NqQX_DYb=kh4XAX3ria1uSVszQkzwShRzpHQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 29, 2018 at 4:32 AM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> After the attached patch applied, the above messages becomes as
> follows. (And index can be built being a bit sparse by fill
> factor.)
>
>> ERROR: index row size 8016 exceeds maximum 7333 for index "y_cube_idx"
>
> I'm not sure why 277807bd9e didn't do that completely so I may be
> missing something. Is there any thoughts?

It seems strange to me that we consider respecting the fillfactor to
be more important than letting the operation succeed. I would have
thought that the fillfactor would not apply when placing a tuple into
a completely empty page. The point of the setting is, of course, to
leave some free space available on the page for future tuples, but if
the tuples are big enough that only one fits in a page anyway, that's
pointless.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lars Kanis 2018-09-01 16:17:16 [PATCH] Fix docs to JOHAB encoding on server side
Previous Message Tom Lane 2018-09-01 14:54:25 Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes