4 ms·

I'm interested to understand why you think it should differ between OLAP and OLTP? Are you suggesting that columns closer to the top matters for OLAP bc OLAP i

• nivertech 3y ago
  1. Not every OLAP/columnar/timeseries DBMS has a Query Planner. For example in kdb+/q a developer need to think about correct order of WHERE clauses, know which columns have attributes (kind of "secondary indexes"), and lots of other tricks. The advantage is predictability of execution, the disadvantage - it's too complex. 2. I'm not talking about cases where a Query Planner parses the query language DSL, and computes Query Plan out of it. More the case when you kind of have an explicit Query Plan. The best example is FluxQL[1]. -- [1]. https://docs.influxdata.com/influxdb/cloud/reference/syntax/flux/flux-vs-influxql/ https://docs.influxdata.com/influxdb/cloud/reference/syntax/...
  • chrisjc 3y ago
    Now that you mention it, I guess I've experienced *similar* issues (more to do with joins, unions, materializations, windows, etc) even when there is a query planner. Even though the query planner has an optimizer, the plan produced isn't optimal. In some cases I have had to play around with the SQL (resulting in less than ideal SQL) to get the optimizer to do what it should. This demonstrates the exact point you made: > The advantage is predictability of execution In my example, while I ultimately overcame the issues with the sub-optimal plan, there's no assurances about what the query planner/optimizer will come up with tomorrow.