On Tue, Aug 1, 2017 at 11:08 PM, Vladimir Ozerov <voze...@gridgain.com>
wrote:
> Own parser capable of processing non-SELECT and non-DML statements.
>
And how will it integrate with H2 parser? Or are you suggesting that we get
rid of H2 SQL parser?
>
> On Tue, Aug 1, 2017 at 9:44 PM, <dsetrak...@apache.org> 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 <
> voze...@gridgain.com>
> > 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
> > ><andrey.mashen...@gmail.com
> > >> 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
> > ><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
> > >>
> >
>
