Vovan,
1. What about ANSI-xx compliant? Will new syntax brake it in some cases or
just extend?
2. This would be great to have more ways for optimization.
Does anyone know or may be have experience with some frameworks or open
projects which can be helpful? E.g. Apache Calcite?
On Tue, Aug 1, 2017 at 3:25 PM, Vladimir Ozerov <voze...@gridgain.com>
wrote:
> 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.
>
--
Best regards,
Andrey V. Mashenkov
