Hi Mitchell,
I believe that research done by Anton is correct, and the root cause of the
OOME is proportion of memory occupied by metapages in data region. Each
cache started in data region allocates one or more metapages per
initialized partition so when you run your test with only one cache
Roman,
What I am trying to understand is what advantage of materialization API you
see over the normal optimization process? Does it save optimization time,
or reduce memory footprint, or maybe provide better plans? I am asking
because I do not see how expressing indexes as materializations fit
I tend to agree with Mitchell that the cluster should not crash. If the
crash is unavoidable based on the current architecture then a message
should be more descriptive.
Ignite persistence experts, could you please join the conversation and shed
more light to the reported behavior?
-
Denis
On
I will look to the MOVING partition issue.
But also need a guidance there.
Ivan, don't you mind to be that person?
The question is whether we have an issue with:
- wrong storing targets during indexing OR
- incorrect nodes/partition selection during querying?
BR,
Yuriy Shluiha
--
Sent
Vladimir,
the main advantage of the Phoenix approach I can see is the using of
Calcite's native materializations API. Calcite has advanced support for
materializations [1] and lattices [2]. Since secondary indexes can be
considered as materialized views (it's just a sorted representation of
the
Pavel Tupitsyn created IGNITE-12437:
---
Summary: .NET: Run tests on macOS TeamCity agent
Key: IGNITE-12437
URL: https://issues.apache.org/jira/browse/IGNITE-12437
Project: Ignite
Issue Type:
Vladimir,
You are right Phoenix integration with Calcite stalled halfway. See
[1] to get some reasons.
[1]
https://lists.apache.org/thread.html/0152a97bfebb85c74f10e26e94ab9cd416dec374abba7dc2e1af9d61%40%3Cdev.phoenix.apache.org%3E
ср, 11 дек. 2019 г. в 17:11, Vladimir Ozerov :
>
> Roman,
>
>
Roman,
What is the advantage of Phoenix approach then? BTW, it looks like Phoenix
integration with Calcite never made it to production, did it?
вт, 10 дек. 2019 г. в 19:50, Roman Kondakov :
> Hi Vladimir,
>
> from what I understand, Drill does not exploit collation of indexes. To
> be precise
Maxim Muzafarov created IGNITE-12436:
Summary: ignite.properties must be handled by maven update-version
profile
Key: IGNITE-12436
URL: https://issues.apache.org/jira/browse/IGNITE-12436
Project:
Alexey Zinoviev created IGNITE-12435:
Summary: [Spark] Add support for saving to existing table via
saveAsTable
Key: IGNITE-12435
URL: https://issues.apache.org/jira/browse/IGNITE-12435
Project:
Stanilovsky Evgeny created IGNITE-12434:
---
Summary: Dump checkpoint readLock holder threads if writeLock
can`t take lock more than threshold timeout.
Key: IGNITE-12434
URL:
Hello!
I have filed an issue https://issues.apache.org/jira/browse/IGNITE-12433
Regards,
--
Ilya Kasnacheev
ср, 11 дек. 2019 г. в 12:43, Denis Magda :
> It sounds like the implementation specificities of Ignite DML.
>
> SQL folks, how about throwing an exception in case of the duplicate
Ilya Kasnacheev created IGNITE-12433:
Summary: Possible to create table with duplicate definition of
column
Key: IGNITE-12433
URL: https://issues.apache.org/jira/browse/IGNITE-12433
Project:
Alexey Zinoviev created IGNITE-12432:
Summary: [Spark] Need to add test for AVG function in
IgniteOptimizationAggregationFuncSpec
Key: IGNITE-12432
URL: https://issues.apache.org/jira/browse/IGNITE-12432
It sounds like the implementation specificities of Ignite DML.
SQL folks, how about throwing an exception in case of the duplicate name?
-
Denis
On Thu, Dec 5, 2019 at 9:38 AM DS
wrote:
> *I am able to create the table with duplicate column name.*
>
> I was expecting some error saying
15 matches
Mail list logo
