This is great news!
Alex, thanks for making it to the end!
--
Regards,
Konstantin Orlov
> On 24 Mar 2022, at 18:07, Alex Plehanov wrote:
>
> Hello Igniters,
>
> I've merged the pull request. The Calcite-based SQL engine is in the master
> branch now.
> If you
Great job!
On Thu, Mar 24, 2022 at 6:27 PM Nikita Amelchev
wrote:
> Great news!
>
> I will cut the 2.13 release branch soon.
>
> чт, 24 мар. 2022 г. в 18:07, Alex Plehanov :
>
> >
> > Hello Igniters,
> >
> > I've merged the pull request.
Great news!
I will cut the 2.13 release branch soon.
чт, 24 мар. 2022 г. в 18:07, Alex Plehanov :
>
> Hello Igniters,
>
> I've merged the pull request. The Calcite-based SQL engine is in the master
> branch now.
> If you desire to try it, you can find configuration in
Hello Igniters,
I've merged the pull request. The Calcite-based SQL engine is in the master
branch now.
If you desire to try it, you can find configuration instructions in
modules/calcite/README.txt file.
вс, 6 мар. 2022 г. в 13:03, Alex Plehanov :
> Hello Igniters,
>
> I'v
Hello Igniters,
I've prepared the pull request [1] and have plans to merge it to the master
branch in about two weeks, if there is no objection.
[1]: https://github.com/apache/ignite/pull/9855
чт, 30 дек. 2021 г. в 13:43, Anton Vinogradov :
> > it would be great to release a new SQ
> it would be great to release a new SQL engine in 2.13 as an
experimental feature.
++1
On Thu, Dec 30, 2021 at 12:55 PM Alex Plehanov
wrote:
> Andrey,
>
> > Is this [1] a full scope of the tickets that MUST be resolved before the
> engine could be merged?
> Yes, we must r
to the readme file on how to turn a
new SQL engine on.
Sure, I think it should be the part of documentation ticket.
> Also, I don't like the module name "ignite-calcite", because Calcite is
an independent project.
Personally, I see no problems here (but it's discussable). We ha
Alex,
it would be great to release a new SQL engine in 2.13 as an
experimental feature.
Is this [1] a full scope of the tickets that MUST be resolved before the
engine could be merged?
I think we have to add instructions to the readme file on how to turn a new
SQL engine on.
Also, I don't
/internal/processors/query/calcite
[3]
https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/sql
>
>>
>>>Hello, Igniters!
>>>
>>>As you may already know there is the new Ignite SQL engine based on Apache
>>>Calcite currently unde
cite" branch [2].
>
> Calcite-based SQL engine is not production-ready yet and has a lot of
> known issues. In the future, the new engine should be fully independent of
> "ignite-indexing" and H2, but now it relies on schema management and
> indexes implemented in the
Hello, Igniters!
As you may already know there is the new Ignite SQL engine based on Apache
Calcite currently under development.
Reasons to move from H2-based engine and motivation for creating the new
one in details described in IEP-37 [1].
You can find all related to the new engine source
Taras Ledkov created IGNITE-14535:
-
Summary: Caclite SQL engine capabilities
Key: IGNITE-14535
URL: https://issues.apache.org/jira/browse/IGNITE-14535
Project: Ignite
Issue Type: Improvement
Yury Gerzhedovich created IGNITE-13971:
--
Summary: Merge Calcite SQL engine to master
Key: IGNITE-13971
URL: https://issues.apache.org/jira/browse/IGNITE-13971
Project: Ignite
Issue Type
Dear Igniters,
Many of you heard about starting development of new SQL engine based on
Calcite. Currently we are only in beginning of the way and it will require
many works to achieve the goal. In order to understand where are we and
which features already done and which of them could be started
#x27;m working on a brand new Calcite based SQL engine.
>
> So, now I have some intermediate results and need a feedback from
> community.
>
> A feature branch with a concept of a module is ignite-12248 <
> https://github.com/apache/ignite/tree/ignite-12248>. The module is go
Hi guys,
Some of you know, I'm working on a brand new Calcite based SQL engine.
So, now I have some intermediate results and need a feedback from community.
A feature branch with a concept of a module is ignite-12248
<https://github.com/apache/ignite/tree/ignite-12248>. The module
not an easy task.
>
>
> On Thu, Oct 18, 2018 at 2:42 AM Igor Tanackovic
> wrote:
>
>> Dmitriy,
>>
>> Correct me if I’m wrong, but the concept is to store everything off heap -
>> which is perfectly fine :). So, the question is how SQL engine actually
>
gine, so this is not an easy task.
On Thu, Oct 18, 2018 at 2:42 AM Igor Tanackovic
wrote:
> Dmitriy,
>
> Correct me if I’m wrong, but the concept is to store everything off heap -
> which is perfectly fine :). So, the question is how SQL engine actually
> works. Analyzing profiler
Dmitriy,
Correct me if I’m wrong, but the concept is to store everything off heap -
which is perfectly fine :). So, the question is how SQL engine actually works.
Analyzing profiler object generation and sizes on heap, I’ve learned that for
each query entire rows in question are copied on heap
:
> Vladimir,
>
> Thanks for explanation... that’s true - ignite never deserialize values
> during query execution. The point here is why copying fields to heap that
> sql engine could not use (not annotated as QuerySqlField)?
> SQL count is a perfect example where you can benefit
Vladimir,
Thanks for explanation... that’s true - ignite never deserialize values
during query execution. The point here is why copying fields to heap that
sql engine could not use (not annotated as QuerySqlField)?
SQL count is a perfect example where you can benefit (heap space and gc)
copying
Moving to dev forum...
Hello,
Seems that SQL engine always deserialize whole objects instead of using just
SQL enabled fields (annotated with @QuerySqlField). This may have a huge
impact on Ignite heap usage and GC overhead as well.
For example, we have a cache holding big objects but with
llo,
>
> Seems that SQL engine always deserialize whole objects instead of using
> just
> SQL enabled fields (annotated with @QuerySqlField). This may have a huge
> impact on Ignite heap usage and GC overhead as well.
>
> For example, we have a cache holding big objects but with only
Hello,
Seems that SQL engine always deserialize whole objects instead of using just
SQL enabled fields (annotated with @QuerySqlField). This may have a huge
impact on Ignite heap usage and GC overhead as well.
For example, we have a cache holding big objects but with only two sql query
fields
Vasiliy Sisko created IGNITE-4874:
-
Summary: SQL engine should throw meaningful exception on query
from local cache
Key: IGNITE-4874
URL: https://issues.apache.org/jira/browse/IGNITE-4874
Project
Alexander Paschenko created IGNITE-4333:
---
Summary: SQL engine does not preserve metadata about array
content's type
Key: IGNITE-4333
URL: https://issues.apache.org/jira/browse/IGNITE
Igniters,
The next week I’ll be conducting the webinar about Apache Ignite SQL Engine
https://www.gridgain.com/resources/webinars/distributed-memory-sql-queries-apacher-ignitetm
<https://www.gridgain.com/resources/webinars/distributed-memory-sql-queries-apacher-ignitetm>
I thought t
Vladimir Ozerov created IGNITE-4149:
---
Summary: Consider adding bitmap index to SQL engine.
Key: IGNITE-4149
URL: https://issues.apache.org/jira/browse/IGNITE-4149
Project: Ignite
Issue
Guys,
I've created two SQL related issues which recently arose in user list:
Correct me if we are already have something similar.
1) https://issues.apache.org/jira/browse/IGNITE-3453
I suppose it's H2 related issue and will be resolved after transition to
1.4 version,
which supports index hints.
Pavel Konstantinov created IGNITE-1338:
--
Summary: SQL engine doesn't convert query fields name in upper
case before using
Key: IGNITE-1338
URL: https://issues.apache.org/jira/browse/IGNITE
30 matches
Mail list logo
