Re: btree_gist into core?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: btree_gist into core?
Date: 2022-01-24 23:29:24
Message-ID: 2164897.1643066964@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andreas Karlsson <andreas(at)proxel(dot)se> writes:
> On 1/19/22 09:30, Peter Eisentraut wrote:
>> I don't have a lot of experience with this module, so I don't know if
>> there are any lingering concerns about whether it is mature enough as a
>> built-in feature.

> While it I like the idea on a conceptual level I worry about the code
> quality of the module. I know that the btree/cidr code is pretty broken.
> But I am not sure if there are any issues with other data types.

Yeah :-(. We just fixed an issue with its char(n) support too
(54b1cb7eb), so I don't have a terribly warm feeling about the
quality of the lesser-used code paths. Still, maybe we could
do some code review/testing rather than a blind copy & paste.

I'd also opine that we don't have to preserve on-disk compatibility
while migrating into core, which'd help get out of the sticky problem
for inet/cidr. This'd require being able to run the contrib module
alongside the core version for awhile (to support existing indexes),
but I think we could manage that if we tried. IIRC we did something
similar when we migrated tsearch into core.

One thing I don't know anything about is how good are btree_gist
indexes performance-wise. Do they have problems that we'd really
need to fix to consider them core-quality?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2022-01-25 01:07:29 Re: GUC flags
Previous Message Mark Dilger 2022-01-24 23:18:03 Re: CREATEROLE and role ownership hierarchies