Trimmed some heavy queries that I was working with from about 4 hours to about 3 minutes. Also compressed the data from 220gb to about 20gb.
Trimmed some heavy queries that I was working with from about 4 hours to about 3 minutes. Also compressed the data from 220gb to about 20gb.
Unfortunately that extension has a bunch of limitations and issues that keep it from being production-ready. PostgreSQL could really use a proper columnstore table implementation, and there's a pluggable storage API on the roadmap but it hasn't gotten much traction yet (and is focused on an in-memory engine first).
http://tech.marksblogg.com/benchmarks.html
More interesting to me is the reverse: using FDW from the analytical DB to Postgres, e.g., https://aws.amazon.com/blogs/big-data/join-amazon-redshift-a...
One of the most interesting things is you can shard postgres extremely easily now by using FDWs which can do native pushdown of optimizations.
Also, Citus itself has been improving in that time, and I'm curious to see how that performs.
For the specific dataset I needed to take advantage of some of the additional datatypes that PG has available, which is how I found it.