Re: [PATCH] reduce page overlap of GiST indexes built using sorted method

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, "sergei sh(dot)" <sshoulbakov(at)kontur(dot)io>
Cc: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] reduce page overlap of GiST indexes built using sorted method
Date: 2023-04-05 04:00:00
Message-ID: fbbfe5dc-3dfa-d54a-3a94-e2bee37b85d8@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

04.02.2022 03:52, Alexander Korotkov wrote:
> Thank you for the revision. This patch looks good to me. I've
> slightly adjusted comments and formatting and wrote the commit
> message.
>
> I'm going to push this if no objections.

While exploring the gist test coverage (that is discussed in [1])
I've found that this block in regress/sql/gist.sql:
-- rebuild the index with a different fillfactor
alter index gist_pointidx SET (fillfactor = 40);
reindex index gist_pointidx;

doesn't do what is declared.
In fact fillfactor is ignored by default now. I've added:
select pg_relation_size('gist_pointidx');
after reindex and get the same size with any fillfactor.
fillfactor = 40: pg_relation_size = 122880
fillfactor = 100: pg_relation_size = 122880

Though size of the index really changes on REL_14_STABLE:
fillfactor = 40: pg_relation_size = 294912
fillfactor = 100: pg_relation_size = 122880

I've found that the behavior changed after f1ea98a79. I see a comment there:
/* fillfactor ignored */
but maybe this change should be reflected on higher levels (tests, docs [2],
RN) too?

For now the fillfactor option still works for the buffering build, but maybe
it could be just made unsupported as it is not supported for gist, brin...

[1] https://www.postgresql.org/message-id/flat/20230331050726.agslrnb7e7sqtpw2%40awork3.anarazel.de
[2] https://www.postgresql.org/docs/devel/sql-createindex.html

Best regards,
Alexander

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Imseih (AWS), Sami 2023-04-05 04:07:21 Re: [BUG] pg_stat_statements and extended query protocol
Previous Message John Naylor 2023-04-05 03:15:57 Re: refactoring relation extension and BufferAlloc(), faster COPY