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