Proposal - Enabling btree_gist by default

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

Responses

Browse pgsql-hackers by date

  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