ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Create own SQL parser
Date Tue, 01 Aug 2017 21:08:26 GMT
Own parser capable of processing non-SELECT and non-DML statements.

On Tue, Aug 1, 2017 at 9:44 PM, <dsetrakyan@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 <vozerov@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.mashenkov@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
> ><vozerov@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
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message