| 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 |
| 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 |