Thread: btree_gist into core?
To use exclusion constraints in practice, you often need to install the btree_gist extension, so that you can combine for example a range type check and normal scalar key columns into one constraint. The currently proposed "application time" feature [0] (also known more generally as temporal database) is in many ways essentially an SQL-syntax wrapper around typical use cases involving ranges, multiranges, and exclusion constraints. As such, it also needs btree_gist installed in most (all?) cases. I have argued over in that thread that it would be weird to have a built-in SQL feature that relied on an extension to work at all. So I think the way forward would be to move btree_gist into core, and I'm starting this new thread here to give this topic a bit more attention. So, first of all, would people agree with this course of action? 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. If we were to do it, then additional discussions could be had about how to arrange the code. I suspect we wouldn't just want to copy the files as is under utils/adt/, since that's a lot of files. There are also of course questions about how to smoothly arrange upgrades from extensions to the built-in situations. Thoughts? [0]: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com
On 1/19/22 09:30, Peter Eisentraut wrote: > So, first of all, would people agree with this course of action? > > 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. See https://www.postgresql.org/message-id/7891efc1-8378-2cf2-617b-4143848ec895%40proxel.se Andreas
Andreas Karlsson <andreas@proxel.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
> Thoughts?
I think it'd be really nice to do this without btree_gist.
I imagine something like this:
CREATE INDEX ON tbl USING gist (
range_col,
int_col USING btree
)
I think this would make the index access methods interface more
useful. Index access method developers wouldn't need to provide
operator classes for all data types. We could extend ACCESS METHOD
definition to allow this:
CREATE ACCESS METHOD my_hash_index
TYPE INDEX
IMPLEMENTS hash
HANDLER my_hash_index_handler
I realise this is a difficult project.
Hi, On Wed, Jan 19, 2022 at 09:30:11AM +0100, Peter Eisentraut wrote: > > To use exclusion constraints in practice, you often need to install the > btree_gist extension, so that you can combine for example a range type check > and normal scalar key columns into one constraint. > > [...] > > There are also of course questions about how to smoothly arrange upgrades > from extensions to the built-in situations. I'm not sure if that's what you were thinking of, but I know at least one extension (that I'm maintaining) that explicitly relies on btree_gist extension, as in "requires = [...], btree_gist" in the .control file. Since you can't really tweak the control file on a per-major-version basis, this will require some extra thoughts to make sure that people can release extensions without having to tweak this file in some make rule or something like that.