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

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, "sergei sh(dot)" <sshoulbakov(at)kontur(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] reduce page overlap of GiST indexes built using sorted method
Date: 2026-08-10 09:04:33
Message-ID: 0C45B219-9313-49DE-8E85-01C6CA9B5421@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 5 Apr 2023, at 09:00, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>
> 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...

Alexander's observation is still valid: sorted GiST builds explicitly
ignore fillfactor. I think it is better to support the option than to
document this as an exception, especially now that more opclasses
provide sortsupport.

The attached patch treats fillfactor as a soft limit while recursively
partitioning the buffered tuples. A physically valid page may exceed
the limit when the opclass split would create a page with only one
tuple. Ordinary GiST page splits are unchanged.

With 20,000 points, fillfactor 90 produced 220 pages and fillfactor 40
produced 442 pages. The test also covers large INCLUDE tuples at
fillfactor 10.

PFA the patch.

Darafei, Alexanders, Sergei do you think this should be added to the Commitfest?

Best regards, Andrey Borodin.

Attachment Content-Type Size
v1-0001-Honor-fillfactor-in-sorted-GiST-builds.patch application/octet-stream 13.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2026-08-10 09:40:48 Re: Error handling in after-startup shmem requests
Previous Message cca5507 2026-08-10 09:02:19 Re: Avoid calling SetMatViewPopulatedState if possible