On 5/18/24 02:00, Paul A Jungwirth wrote: > 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. >
I believe that's pretty much what the existing patch [1] linked by Andrey (and apparently running for a number of CFs) does. [1] https://commitfest.postgresql.org/48/3686/ > 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. > Yeah, I happened to branch from a slightly older master, not noticing this is affected by the revert. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
