3 ms·
> The same query when ran on DB2 took 12 hours, on postgres (5x more data) it took 24 hours. You're doing it wrong. These type of queries should be run on a co
by assface 11y ago
> The same query when ran on DB2 took 12 hours, on postgres (5x more data) it took 24 hours.
You're doing it wrong. These type of queries should be run on a column store (e.g., Vertica).
- esaym 11y agoAll the money was flowing to IBM licenses. Hence when we needed another database for reporting, we went with open source. Vertica is big money++ And really, after my stint with that company, I really can't stand commercialized licensed software anymore.
- CuriousSkeptic 11y agoDid you look inte monetdb? I'm curios about real world experiences with that one.
- greggyb 11y agoThe problem isn't the technology here. The problem is that they were using a replica of the OLTP database for reporting purposes. OLTP and OLAP are hugely different workloads. A good 3NF (or close to it) schema that you'll find in an OLTP database is designed for fast writes with minimal locking; it fits well with the workload of OLTP. If you're reporting on that data and performing analytical queries, then your schema needs to reflect that and optimize for large reads without much concern around lock contention for the primary workload. I am not opposing the suggestion of a columnstore database, as we utilize these extensively with our clients. There is simply a much larger problem in the specified example. 15B rows is not too big a deal in an RDBMS for an analytical workload.