Hacker News Reader

Comment by coderzach | Hacker News Reader

Not OP, but for us, the reasons we switched from postgres to sql server were the "clustered columnstore indexes" and query parallelization. Before switching to sql server, we spent a ton of time optimizing query performance with "clever" use of indexes, ctes, etc. With sql server, we've been able to just use the columnstore indexes and write simple, straightforward queries that run in ~200ms vs 10-20 seconds in postgres.

And before you ask, we spent A TON if time and money on configuration, paying for multiple postgres experts to help with optimization.

View on HN

I mean, if you were already jumping over to using columnstore tables why not use Cassandra? I guess CQL has a lot of limits that SQL doesn't, but if your use-case matches a columnstore it's an option to consider.

My guess would be the integration with everything that wasn't a columnstore... Being able to do both in the same dbms is an advantage. Also, doing everything in Cassandra is hard, and takes a lot of planning and effort that may have not been available.

I can't speak to their specific use cases though. I've been a bit of a RethinkDB fan myself in terms of straddling paradigms. I hope they shake out into a foundation structure with as much as possible in tact.

I do think that once PostgreSQL gets some of the clustering/HA features in the box and shaken out, it will become the default option for most uses. As it stands MSSQL does have some compelling advantages, some of which you pay for.

> I do think that once PostgreSQL gets some of the clustering/HA features in the box and shaken out, it will become the default option for most uses. As it stands MSSQL does have some compelling advantages, some of which you pay for.

Or even a add-on that's not so difficult to configure. EnterpriseDB has made strides here, but justifying the license cost is harder for me now that they've moved to their new Unicore model.

`repmgr` from 2ndQuadrant is getting really close to ideal and it's included in the PGDG yum and apt repositories, my biggest issue is the manual plumbing involved to get clients to automatically pick up the new master after a failover and automatically rewinding a failed master and bringing it back up as a standby (both are done out of the box by EDB's solution).

Cassandra really isn't a columnstore in the same sense that the word is used for OLAP systems. In the latter, efficient queries can be run across lots of values in a small number of columns across many rows. In Cassandra, queries spanning many rows are not particularly efficient. Sometimes wide-column tables are used for OLAP-type use cases in Cassandra, but that's something of a different approach. More info on that here: http://dbmsmusings.blogspot.com/2010/03/distinguishing-two-m...

Interesting. I guess it sometimes shows that paying the license fee can be worth from a business's point of view it if it avoids consultants' fees associated with an open source solution.

What version(s) of PostgreSQL were you using?

9.5, however we did experiment with 9.6 when it was in beta, due to the parallel sequential scan feature, but it didn't seem to help much.

Reply on news.ycombinator.com