Igniters,
As you know, we rely on H2 for SQL query parsing. This has several
drawbacks:
1) Limited and ugly syntax
Ignite has lot's of unique concepts which are in no way supported by
traditional RDBMS in general, or by H2 in particular. For example:
- query hints ("distributedJoins", "replicatedOnly", "colocated")
- index hints ("inline size")
- cache configuration (memory policy, affinity key, cache mode, etc)
- transaction mode (concurrency, isolation, timeouts) - not needed now, but
will be required when transactional SQL is ready
2) Performance implications
Typical SQL processing flow looks as follows
- Parse String to H2 object form (prepared statement)
- Convert it to Ignite object form (AST)
- Then convert it back to map and reduce queries in String form
- Convert map and reduce queries from String back to H2 PreparedStatement
again for final execution
This is way too much. Moreover, H2 optimizes query during parsing, but it's
optimizer is not smart enough. E.g., Ignite "IN" clauses are not optimized
and hence doesn't use indexes, so we force users to use intermediate tables
with very ugly syntax, while we should do that on our own instead. Another
example is common expression elimination - H2 cannot do that even for
deterministic functions, what cause performance problems frequently.
I propose to start some work in direction of our own parser. We can start
with something very simple, e.g. DDL support, which is not that complex,
but will improve usability significantly. And then gradually extend it to
more complex statements where both rich BNF and optimizer is necessary.
Thoughts?
Vladimir.
