chore(deps): update dependency gburd/pg_fts to v1.1.0 #22

Merged

AzSiAz merged 1 commit from renovate/gburd-pg_fts-1.x into main

2026-07-26 16:06:51 +02:00

AzSiAz commented

2026-07-26 16:00:30 +02:00

Owner

This PR contains the following updates:

Package	Update	Change
gburd/pg_fts	minor	`1.0.8` → `1.1.0`

Release Notes

gburd/pg_fts (gburd/pg_fts)

`v1.1.0`

Compare Source

Build-convergence and operability release. No on-disk format change from
1.0.8; no REINDEX required (ALTER EXTENSION pg_fts UPDATE TO '1.1.0').

Fixed a non-converging index build on large, high-vocabulary corpora.
Building an index over many long, high-vocabulary documents (full email
bodies, source code, patches -- many distinct low-frequency terms per doc)
could enter a merge phase that ran for hours with no forward progress and
never completed, even though memory stayed bounded. The cause was a
quadratic (O(N^2)) construction of each trigram's term-set during the merge;
it is now built with a bulk O(N) path. A build that previously did not finish
in 8.5 hours completes in minutes.
Large builds now always converge, in bounded steps. Instead of always
collapsing to a single segment at the end of a build (a single-backend pass
over the whole index), a build whose total size exceeds the new
pg_fts.build_collapse_max_mb GUC (default 4096 MB) stops at a bounded,
size-tiered set of segments. The index is valid and fully queryable; ranked
scans traverse a bounded handful of segments (a small fixed cost). Run
fts_merge(index) to collapse to a single optimal segment in a maintenance
window. Set the GUC to 0 to always collapse (the historical behavior), or
raise it to collapse larger indexes during the build.
Build monitoring. Per-merge progress is logged at DEBUG1 (segments in,
terms/docs written, elapsed), and a LOG line reports when a build stops at a
tiered set. fts_index_nsegments() now works on an in-progress
(indisvalid = f) index, so a build can be polled to watch its segment count
fall as merges complete.
Docs: a new "Building indexes on large or high-vocabulary corpora" section
covers the build-memory formula (including shared_buffers), the collapse
GUC, monitoring, and partitioning.

Configuration

📅 Schedule: (in timezone Europe/Paris)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | [gburd/pg_fts](https://github.com/gburd/pg_fts) | minor | `1.0.8` → `1.1.0` | --- ### Release Notes <details> <summary>gburd/pg_fts (gburd/pg_fts)</summary> ### [`v1.1.0`](https://github.com/gburd/pg_fts/blob/HEAD/CHANGELOG.md#110) [Compare Source](https://github.com/gburd/pg_fts/compare/v1.0.8...v1.1.0) Build-convergence and operability release. **No on-disk format change** from 1.0.8; no **REINDEX** required (`ALTER EXTENSION pg_fts UPDATE TO '1.1.0'`). - **Fixed a non-converging index build on large, high-vocabulary corpora.** Building an index over many long, high-vocabulary documents (full email bodies, source code, patches -- many distinct low-frequency terms per doc) could enter a merge phase that ran for hours with no forward progress and never completed, even though memory stayed bounded. The cause was a quadratic (O(N^2)) construction of each trigram's term-set during the merge; it is now built with a bulk O(N) path. A build that previously did not finish in 8.5 hours completes in minutes. - **Large builds now always converge, in bounded steps.** Instead of always collapsing to a single segment at the end of a build (a single-backend pass over the whole index), a build whose total size exceeds the new `pg_fts.build_collapse_max_mb` GUC (default 4096 MB) stops at a bounded, size-tiered set of segments. The index is valid and fully queryable; ranked scans traverse a bounded handful of segments (a small fixed cost). Run `fts_merge(index)` to collapse to a single optimal segment in a maintenance window. Set the GUC to 0 to always collapse (the historical behavior), or raise it to collapse larger indexes during the build. - **Build monitoring.** Per-merge progress is logged at `DEBUG1` (segments in, terms/docs written, elapsed), and a `LOG` line reports when a build stops at a tiered set. `fts_index_nsegments()` now works on an in-progress (`indisvalid = f`) index, so a build can be polled to watch its segment count fall as merges complete. - **Docs:** a new "Building indexes on large or high-vocabulary corpora" section covers the build-memory formula (including `shared_buffers`), the collapse GUC, monitoring, and partitioning. </details> --- ### Configuration 📅 **Schedule**: (in timezone Europe/Paris) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).

AzSiAz added 1 commit

2026-07-26 16:00:30 +02:00

chore(deps): update dependency gburd/pg_fts to v1.1.0

ci/woodpecker/pr/pr Pipeline was successful

Details

4067bd9a20

AzSiAz scheduled this pull request to auto merge when all checks succeed

2026-07-26 16:00:30 +02:00

AzSiAz merged commit 802db70eed into main

2026-07-26 16:06:51 +02:00

AzSiAz deleted branch renovate/gburd-pg_fts-1.x

2026-07-26 16:06:51 +02:00