From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A strange GiST error message or fillfactor of GiST build |
Date: | 2018-09-03 15:16:02 |
Message-ID: | CAPpHfduLdrAZGrFe=sznWyTpx5HsHuXK9o_bEYxHNAYyrmOjXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Sep 1, 2018 at 9:45 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> > Thus, I would vote for removing GiST fillfactor altogether. Assuming
> > we can't do this for compatibility reasons, I would vote for setting
> > default GiST fillfactor to 100, and don't introduce new places where
> > we take it into account.
>
> We probably can't remove the fillfactor storage parameter, both for
> backwards compatibility and because I think it's implemented independently
> of index type. But there's no backwards-compatibility argument against
> simply ignoring it, if we conclude it's a bad idea.
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.
I think I need to prove my position about GiST fillfactor with some
experiments first, and then propose a patch.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-09-03 16:01:21 | Caching query plan costs |
Previous Message | Jean-Pierre Pelletier | 2018-09-03 15:07:35 | Out arguments name of "pg_identify_object_as_address" function in 9.5.14 and 11beta3 |