Own parser capable of processing non-SELECT and non-DML statements. On Tue, Aug 1, 2017 at 9:44 PM, <[email protected]> wrote:
> Vova, I am not sure what you are proposing... extending H2 parser with new > syntax or a brand new parser? > > D. > > On Aug 1, 2017, 4:26 PM, at 4:26 PM, Vladimir Ozerov <[email protected]> > wrote: > >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 > >> >
