Andrey, Note that I am not proposing to remove H2 as a whole. Main point for now is to support missing pieces of DDL syntax and possibly and some extensions. Several examples:
1) Currently CREATE TABLE command looks ugly: CREATE TABLE Person (id LONG, name VARCHAR) WITH "template=PARTITIONED, backups=1, ..." Commas typically treated in a special way in editors and IDEs, so user will have to escape them, making usability even worse. 2) What if I need to introduce new template? Currently you have to restart the node with new config. With our own parser you will do: CREATE TEMPLATE my_template MODE=PARTITIONED, BACKUPS=1; CREATE TABLE Person (...) TEMPLATE my_template; No restarts, everything is done dynamically. On Tue, Aug 1, 2017 at 4:18 PM, Andrey Mashenkov <[email protected] > wrote: > 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 <[email protected]> > 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 >
