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.
Yep. In our case we were using it for scheduling purposes and "Who is free on thursday at 2pm?" and we got very little narrowing because most people are available at least some time in the morning and some time in the evening.
We've loosely landed at just materializing the dataset into another table by calling `unnest` in a trigger and then using an index on that table.
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.
And it has some mistakes: for example, in Postgres TIMESTAMP WITH TIME ZONE doesn't store the time zone. It's more like Oracle's TIMESTAMP WITH LOCAL TIME ZONE: it converts the timestamp to UTC when storing and converts it to the session's time zone when retrieving.
I would argue that at least at the time that webpage was written and maintained, none, of them (including the standard) got timestamps right. In the above case timezone is actually an offset.
Arguably, timestamp with timezone should store a timestamp plus a tz_database time zone. Storing offsets is easy and useful but not necessarily correct. Timestamp with Offset should be a different type.
Validating all of those rules would be a hairy mess. For example, what do you do with a timestamp in the future when changes are introduced (negative leap seconds, changes to DST, geopolitical changes affecting timezones).
One thing that comes to mind is that you have to quote table and column names that don't follow the identifier pattern [like so] instead of "like so". Though I haven't kept up to date on this, maybe it can now also support SQL standard compliant table/column name quoting. Even MySQL can now do that (with a config option, at least).
That's only a tiny thing, though. I'm sure there is more. I don't use Microsoft SQL Server. Quite happy with PostgreSQL (and SQLite for tiny in file things).
I agree, you'll never hear me recommend MSSQL to anyone, but it's unfortunately quite popular among my customers and hence something I have to take into account when buying software.
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.
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).
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:
33 comments
[ 4.3 ms ] story [ 58.5 ms ] threadsrc: https://github.com/postgres/postgres/blob/f14aad5169baa5e2ac...
We've loosely landed at just materializing the dataset into another table by calling `unnest` in a trigger and then using an index on that table.
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...
There was a website comparing the major RDBMSs to the standard with examples. I can not find it now but I found this:
https://en.wikipedia.org/wiki/SQL_compliance
Edit: this was it https://troels.arvin.dk/db/rdbms/
It's not updated though.
Arguably, timestamp with timezone should store a timestamp plus a tz_database time zone. Storing offsets is easy and useful but not necessarily correct. Timestamp with Offset should be a different type.
Validating all of those rules would be a hairy mess. For example, what do you do with a timestamp in the future when changes are introduced (negative leap seconds, changes to DST, geopolitical changes affecting timezones).
That's only a tiny thing, though. I'm sure there is more. I don't use Microsoft SQL Server. Quite happy with PostgreSQL (and SQLite for tiny in file things).
(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)
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.
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).
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).
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
> The array containment operators (<@ and @>) [...]
https://www.postgresql.org/docs/9.6/functions-array.html