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
>>
