Just want to throw out the usefulness of multiranges in my current domain, which is spectrum regulation/licensing. A few of our processes enabled by multirange support have caught serious exclusivity conflicts (where there are more than one licensee with exclusive rights to a specific span of spectrum within a specific geographic area) with licenses that were not caught by the FCC before they were issued. Additionally useful for swaps (where licensees trade licenses to improve their holdings relative to their existing portfolio)...multiranges allow for easy and error free analysis of potential swap targets that maximize benefit to both parties. And we also use it for spot checks to make sure that we are using spectrum legally according to the special conditions constraints (e.g. not using 600MHz A block within a distance that could cause interference with hospital usage of WMTS equipment). I love range types!
yeah they've been super useful for me too. i haven't switched to the multirange datatype yet (still use int4range[]), but I'm excited to since you can now do exclusion constraints on multiranges, which will greatly simplify some things for me.
i keep track of roads that a person has biked/walked for Wandrer (wandrer.earth), and storing everything as a geometry would be a storage and analytical nightmare. keeping things as a range lets you easily determine what part of an activity covered new ground, and you can generate the geometry / length on demand while only storing a few integers (plus the raw road geometry, but that's shared among everyone).
It’s also worth knowing that you can accelerate many sorts of range queries with a GIST index. This often ends up faster than using two separate columns.
Right, but it just means the index is not used as the final source of truth and the DB has to run an exact check on the smaller subset of rows returned. You won't get incorrect queries, but depending on the workload it may not be a useful index for improving query speed.
I've used tsrange successfully in 2 projects to optimise storage of temporal data.
The same can be achieved with start/end timestamp columns at the cost of more complex and error prone queries.
Multiranges could be used to further optimise for storage of duplicate data (if a data pattern repeats at different intervals) but it's not a big enough margin for me yet.
I really like PostgreSQL ranges, but I've always been curious, if these are an extension or they are a part of the SQL standard? The “Range Types” page[1] doesn't seem to mention the standard at all, and appendix D.1, “Supported Features”, doesn't mention range types.
The reason I'm curious is because may future SQL database implementations will most likely use the standard at least in some capacity, so it'd be nice to know, how future-proof and DBMS-switch-proof a schema using these could be.
I'm still hoping to use multiranges to add temporal tables to Postgres, but life has been busy the last year. I apologize to you all for the delay.
The coolest application of multiranges I've heard about is for astronomical observations. The authors of this paper were kind enough to share an early draft with me, and they say it greatly speeds up comparisons of sky objects. It's very accessible and a fun read:
Readit News
i keep track of roads that a person has biked/walked for Wandrer (wandrer.earth), and storing everything as a geometry would be a storage and analytical nightmare. keeping things as a range lets you easily determine what part of an activity covered new ground, and you can generate the geometry / length on demand while only storing a few integers (plus the raw road geometry, but that's shared among everyone).
src: https://github.com/postgres/postgres/blob/f14aad5169baa5e2ac...
Multiranges could be used to further optimise for storage of duplicate data (if a data pattern repeats at different intervals) but it's not a big enough margin for me yet.
The reason I'm curious is because may future SQL database implementations will most likely use the standard at least in some capacity, so it'd be nice to know, how future-proof and DBMS-switch-proof a schema using these could be.
[1]: https://www.postgresql.org/docs/current/rangetypes.html
[2]: https://www.postgresql.org/docs/current/features-sql-standar...
(The word ‘range’ appears once there, in “F404. Range variable for common column names”, but reading the English parts of https://github.com/dazuiba008/digoal_blog_fork/blob/master/2..., it’s clear that isn’t about range types)
The coolest application of multiranges I've heard about is for astronomical observations. The authors of this paper were kind enough to share an early draft with me, and they say it greatly speeds up comparisons of sky objects. It's very accessible and a fun read:
https://arxiv.org/abs/2112.06947
Dead Comment
> The array containment operators (<@ and @>) [...]
https://www.postgresql.org/docs/9.6/functions-array.html
What's the performance like to get multiranges from a million row column of unique integers, that has a few gaps in it.
(Also slightly unsorted, but obv can do that in query).