3 ms·
Would be a nice enhancement if it was in vanilla Postgres, otherwise I don't quite put too much trust in this. Few real world queries are this simple and I don'
by endymi0n 11y ago
Would be a nice enhancement if it was in vanilla Postgres, otherwise I don't quite put too much trust in this. Few real world queries are this simple and I don't think there are many gains left when executed against a more real-world TPC benchmark suite. But even if this was the case, it's probably better to take something better suited for this use case, like Redshift, BigQuery or Hive.
On top, my gut feeling tells me this company seems a little shady and their business model seems unclear to me. Are they for real?
- quizotic 11y agoWhile not 'vanilla' Postgres, this appears to be packaged reasonably as a PG extension. Since no vanilla PG code was changed, you should be able to upgrade PG without worry. PG 9.5 introduces some support for parallelization along with custom scans. So this capability seems like a natural fit. As for utility, big data queries tend to do heavy aggregations, and parallelization is a nice performance enhancement where it could be sorely needed. Redshift has good name recognition, but under the covers, it's ParAccel, which started with an early (8.2?) version of Postgres and modified it.
- omni 11y agoRedshift is based on Postgres 8.0.2. You constantly run into stuff you're used to from modern Postgres that you can't do. :(
- joevandyk 11y agoI think the parallel stuff is in 9.6, not 9.5. http://rhaas.blogspot.com/2015/11/parallel-sequential-scan-is-committed.html http://rhaas.blogspot.com/2015/11/parallel-sequential-scan-i...