On Fri, May 17, 2024 at 12:41 PM Tomas Vondra
<tomas.vondra@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