| From: | Alastair Turner <minion(at)decodable(dot)me> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Proposal - Enabling btree_gist by default |
| Date: | 2026-01-05 01:03:51 |
| Message-ID: | CAC0GmyzO-LPkHG=yG7G6WkNvk-_Mm1H6SRS_5QvSuX+-seR+PQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
That btree_gist is key to making exclusion constraints useful, which
creates a case for it to be enabled by default, came up at the extensions
summit at PGConf.dev last year. As part of mopping up my todo for last
year, I'd like to present the idea for review with a WIP patch.
0002 is the minimal enabling of the extension in initdb and adapting the
test to deal with the extension already existing
0001 is a preparatory patch which resets the search path after creating the
information schema in initdb, so btree_gist gets created in the right
place. The RESET may not be the best approach, maybe these steps need to be
wrapped in transactions so that SET LOCAL can be used in the scripts?
There is more cleanup/adaptation I need to do on the test side - having
btree_gist in the initdb image breaks various things including the type and
operator sanity checks.
Before wading into all of that - what is the view on enabling btree_gist by
default in initdb?
Thanks
Alastair
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Reset-search_path-after-initialising-information_sch.patch | text/x-patch | 714 bytes |
| 0002-Enable-btree_gist-by-default.patch | text/x-patch | 2.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Karlsson | 2026-01-05 01:09:56 | Re: Use Postgres as meson wrap subproject |
| Previous Message | Richard Guo | 2026-01-05 00:52:12 | Re: pgsql: Ignore PlaceHolderVars when looking up statistics |