On Fri, May 17, 2024 at 12:41 PM Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > I've been looking at GiST to see if there could be a good way to do > parallel builds - and there might be, if the opclass supports sorted > builds, because then we could parallelize the sort. > > But then I noticed we support this mode only for point_ops, because > that's the only opclass with sortsupport procedure. Which mostly makes > sense, because types like geometries, polygons, ... do not have a well > defined order.
Oh, I'm excited about this for temporal tables. It seems to me that ranges and multiranges should have a well-defined order (assuming their base types do), since you can do dictionary-style ordering (compare the first value, then the next, then the next, etc.). Is there any reason not to support those? No reason not to commit these btree_gist functions first though. If you aren't interested in adding GiST sortsupport for ranges & multiranges I'm willing to do it myself; just let me know. Do note that the 1.7 -> 1.8 changes have been reverted though (as part of my temporal work), and it looks like your patch is a bit messed up from that. You'll want to take 1.8 for yourself, and also your 1.9 upgrade script is trying to add the reverted stratnum functions. Yours, Paul
