Hi Pavel,
Yes, I missed the list, sorry.
ср, 19 мая 2021 г. в 14:40, Pavel Tupitsyn :
> Hi Vladimir,
>
> Looks like this message is for d...@calcite.apache.org, not
> dev@ignite.apache.org,
> or am I mistaken?
>
> On Wed, May 19, 2021 at 2:25 PM Vladimir Ozerov
> wrot
Hi,
The AggregateUnionTransposeRule attempts to push the Aggregate below the
Union.
Before:
Aggregate[group=$0, agg=SUM($1]
Union[all]
Input1
Input2
After:
Aggregate[group=$0, agg=SUM($1]
Union[all]
Aggregate[group=$0, agg=SUM($1]
Input1
Aggregate[group=$0, agg=SUM($1]
Congratulations, Taras!
Well deserved!
вт, 12 мая 2020 г. в 20:27, Ivan Rakov :
> Taras,
>
> Congratulations and welcome!
>
> On Tue, May 12, 2020 at 8:26 PM Denis Magda wrote:
>
> > Taras,
> >
> > Welcome, that was long overdue on our part! Hope to see you soon among
> the
> > PMC group.
> >
>
Hi Alexey, Igniters,
Let me introduce you Heather, Zoran, and Frank. Heather is the Chair of the
JCP. Zoran and Frank are JSR 381 spec leads. They are interested in
discussing the upcoming visual recognition specification with the Apache
Ignite community, to understand whether the community has an
materialized_views.html
> [2] https://calcite.apache.org/docs/lattice.html
>
> --
> Kind Regards
> Roman Kondakov
>
>
> On 11.12.2019 17:11, Vladimir Ozerov wrote:
> > Roman,
> >
> > What is the advantage of Phoenix approach then? BTW, it looks like
> Pho
lying DbScanSortRemovalRule we have:
>
> Project
> IndexScan
>
> while for Phoenix approach we would have two equivalent subsets in our
> planner:
>
> Project
> Sort
> TableScan
>
> and
>
> Project
> IndexScan
>
> and most likely the last plan
Hi Roman,
Why do you think that Drill-style will not let you exploit collation?
Collation should be propagated from the index scan in the same way as in
other sorted operators, such as merge join or streaming aggregate. Provided
that you use converter-hack (or any alternative solution to trigger p
global communications.
>
> - Roman Shtykh.
> Rocketmq and Ignite committer.
> Highly involved to Ignite development and popularization.
>
> - Vladimir Ozerov
> Ignite and Hazelcast committer.
> Man with really strong leadership skills.
>
> - Yakov Zhdanov
> Igni
Vladimir Ozerov created IGNITE-11701:
Summary: SQL: Reflect in documentation change of system views
schema from "IGNITE" to "SYS"
Key: IGNITE-11701
URL: https://issues.apache.org/jira
> >> > > > > can start with thread-per-connection approach (we only can
> support
> >> > one
> >> > > > > active transaction per connection, see below, so we need one
> >> > additional
> >> > > > > dedicated th
Vladimir Ozerov created IGNITE-11648:
Summary: Document SCHEMAS system view
Key: IGNITE-11648
URL: https://issues.apache.org/jira/browse/IGNITE-11648
Project: Ignite
Issue Type: Task
end the old transaction
> implicitly (rollback) or throw an exception to the client? In my opinion,
> the first option is better. For example, if we got a previously used
> connection from the connection pool, we should not worry about any
> uncompleted transaction started by the previ
As far as SUSPEND/RESUME/SAVEPOINT - we do not support them yet, and adding
them in future should not conflict with simple START/END infrastructure.
On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov
wrote:
> Hi Alex,
>
> I am not sure we need 5 commands. Wouldn't it be enough to
> > > > > operation we have the next options:
> > > > > > * Serialize full set of arguments and use some value for missing
> > > > > > arguments. For example -1 for int/long types and null for string
> > > type.
> > > > We
> &g
Vladimir Ozerov created IGNITE-11630:
Summary: Document changes to SQL views
Key: IGNITE-11630
URL: https://issues.apache.org/jira/browse/IGNITE-11630
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11564:
Summary: SQL: Implement KILL QUERY command
Key: IGNITE-11564
URL: https://issues.apache.org/jira/browse/IGNITE-11564
Project: Ignite
Issue Type
Hi,
This is tough question, and first of all I'd like to ask participants to
keep cold head. This is a public question and can be discussed on the dev
list safely.
On the one hand, it is true that a number of patches are not reviewed for a
long time, what negatively affects community development.
Vladimir Ozerov created IGNITE-11551:
Summary: SQL: Document LOCAL_SQL_QUERY_HISTORY
Key: IGNITE-11551
URL: https://issues.apache.org/jira/browse/IGNITE-11551
Project: Ignite
Issue Type
Vladimir Ozerov created IGNITE-11518:
Summary: SQL: Security checks are skipped on some SELECT paths
Key: IGNITE-11518
URL: https://issues.apache.org/jira/browse/IGNITE-11518
Project: Ignite
Vladimir Ozerov created IGNITE-11517:
Summary: MVCC: Support one-phase commit
Key: IGNITE-11517
URL: https://issues.apache.org/jira/browse/IGNITE-11517
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11516:
Summary: MVCC management and monitoring
Key: IGNITE-11516
URL: https://issues.apache.org/jira/browse/IGNITE-11516
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11515:
Summary: MVCC: Make sure that multiple cursors are handled
properly for JDBC/ODBC
Key: IGNITE-11515
URL: https://issues.apache.org/jira/browse/IGNITE-11515
Vladimir Ozerov created IGNITE-11514:
Summary: MVCC: Client listener: do not delegate implicit operation
execution to separate thread for JDBC/ODBC
Key: IGNITE-11514
URL: https://issues.apache.org/jira/browse
Vladimir Ozerov created IGNITE-11513:
Summary: MVCC: make sure that unsupported features are documented
properly
Key: IGNITE-11513
URL: https://issues.apache.org/jira/browse/IGNITE-11513
Project
Vladimir Ozerov created IGNITE-11511:
Summary: SQL: Possible bug with parameters passing for complex DML
queries
Key: IGNITE-11511
URL: https://issues.apache.org/jira/browse/IGNITE-11511
Project
Vladimir Ozerov created IGNITE-11510:
Summary: SQL: Rework running queries tests to make them stable to
internal code changes
Key: IGNITE-11510
URL: https://issues.apache.org/jira/browse/IGNITE-11510
ge, it says the master is release ready branch.
>
> Otherwise feature is developed in its own branch.
>
> So my vote goes for master-based release.
>
> чт, 7 мар. 2019 г. в 20:28, Vladimir Ozerov :
>
> > Igniters,
> >
> > Making release from master is not an opt
Igniters,
Making release from master is not an option. We have a lot of not-yet-ready
and not-yet-tested features. From SQL side this is partition pruning and
SQL views with KILL command.
So if we do not want to release a mess, then there are only two options:
release Java 11 fixes on top of 2.7,
Vladimir Ozerov created IGNITE-11499:
Summary: SQL: DML should not use batches by default
Key: IGNITE-11499
URL: https://issues.apache.org/jira/browse/IGNITE-11499
Project: Ignite
Issue
Vladimir Ozerov created IGNITE-11498:
Summary: SQL: Rework DML data distribution logic
Key: IGNITE-11498
URL: https://issues.apache.org/jira/browse/IGNITE-11498
Project: Ignite
Issue
Hi Pavel,
As far as I know batch tree updates already being developed. Alex, could
you please elaborate?
On Tue, Mar 5, 2019 at 5:05 PM Pavel Pereslegin wrote:
> Hi Igniters!
>
> I am working on implementing batch updates in PageMemory [1] to
> improve the performance of preloader, datastreamer
Hi Val,
I would say that we do not need string length at all, because it can be
derived from object footer (next field offset MINUS current field offset).
It is not very good idea to implement proposed change in Apache Ignite 2.x
because it is breaking and will add unnecessary complexity to alread
Looks like everything is good now - all three commits were returned.
On Mon, Mar 4, 2019 at 2:04 PM Dmitriy Pavlov wrote:
> Thanks, Ivan, these commits are in sync in GitHub & GitBox. Only one commit
> remained, Vladimir O., please chime in
>
> пн, 4 мар. 2019 г. в 14:03, Ivan Rakov :
>
> > Than
nds on that and
> it isn't fixable easily.
>
> For example, they can have objects of which only subset of fields is
> indexed, the rest is not. Then they are inserting them via SQL as shown.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 27 февр. 2019 г. в 12:10
t; Ok, agreed, let's not boil the ocean...at least for now ;)
>
> --
> Denis Magda
>
>
> On Sat, Feb 23, 2019 at 12:50 AM Vladimir Ozerov
> wrote:
>
> > Denis,
> >
> > Yes, this is what my answer was about - you cannot have SQL without
> > defi
Vladimir Ozerov created IGNITE-11422:
Summary: Remove H2 console from documentation
Key: IGNITE-11422
URL: https://issues.apache.org/jira/browse/IGNITE-11422
Project: Ignite
Issue Type
Vladimir Ozerov created IGNITE-11418:
Summary: Document SQL IGNITE.INDEXES view
Key: IGNITE-11418
URL: https://issues.apache.org/jira/browse/IGNITE-11418
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11404:
Summary: Document CREATE TABLE "parallelism" option
Key: IGNITE-11404
URL: https://issues.apache.org/jira/browse/IGNITE-11404
Project: Ignite
Vladimir Ozerov created IGNITE-11402:
Summary: SQL: Add ability to specift inline size of PK and
affinity key indexes from CREATE TABLE and QueryEntity
Key: IGNITE-11402
URL: https://issues.apache.org/jira
ties.
>
> Basically, my idea is that all of the objects and their fields stored in
> the caches should be visible to SQL w/o extra settings. If someone wants to
> create indexes then use DDL which was designed for this.
>
>
> -
> Denis
>
>
> On Fri, Feb 22,
Denis,
SQL is a language with strict schema what was one of significant factors of
it's worldwide success. I doubt we will ever have SQL without
configuration/definiton, because otherwise it will be not SQL, but
something else (e.g. document-oriented, JSON, whatever).
On Fri, Feb 22, 2019 at 1:52
Vladimir Ozerov created IGNITE-11341:
Summary: SQL: Enable lazy mode by default
Key: IGNITE-11341
URL: https://issues.apache.org/jira/browse/IGNITE-11341
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11340:
Summary: SQL: Add OOME tests to separate suite
Key: IGNITE-11340
URL: https://issues.apache.org/jira/browse/IGNITE-11340
Project: Ignite
Issue Type
Vladimir Ozerov created IGNITE-11334:
Summary: SQL: Deprecate SqlQuery
Key: IGNITE-11334
URL: https://issues.apache.org/jira/browse/IGNITE-11334
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11333:
Summary: SQL: Deprecate H2 console
Key: IGNITE-11333
URL: https://issues.apache.org/jira/browse/IGNITE-11333
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11331:
Summary: SQL: Remove unnecessary parameters binding
Key: IGNITE-11331
URL: https://issues.apache.org/jira/browse/IGNITE-11331
Project: Ignite
Issue
Vladimir Ozerov created IGNITE-11326:
Summary: SQL: Common parsing logic
Key: IGNITE-11326
URL: https://issues.apache.org/jira/browse/IGNITE-11326
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11325:
Summary: SQL: Single place to start missing caches
(H2Utils.checkAndStartNotStartedCache)
Key: IGNITE-11325
URL: https://issues.apache.org/jira/browse/IGNITE-11325
Vladimir Ozerov created IGNITE-11317:
Summary: Document that SQL DML statements (UPDATE/MERGE) cannot
update key fields
Key: IGNITE-11317
URL: https://issues.apache.org/jira/browse/IGNITE-11317
Hi Dmitriy,
It is very common practice to keep client protocol compatible with multiple
versions of the server. We constantly face this in practice. I do not see
any reason to drop or complicate this functional: user just connects to the
server and we automatically negotiate on the best feature se
Vladimir Ozerov created IGNITE-11316:
Summary: SQL: Support partition pruning for local queries
Key: IGNITE-11316
URL: https://issues.apache.org/jira/browse/IGNITE-11316
Project: Ignite
Vladimir Ozerov created IGNITE-11310:
Summary: SQL: remove special interaction between query parallelism
and distributed joins
Key: IGNITE-11310
URL: https://issues.apache.org/jira/browse/IGNITE-11310
Vladimir Ozerov created IGNITE-11304:
Summary: SQL: Common caching of both local and distributed query
metadata
Key: IGNITE-11304
URL: https://issues.apache.org/jira/browse/IGNITE-11304
Project
Vladimir Ozerov created IGNITE-11280:
Summary: SQL: Cache all queries, not only two-step
Key: IGNITE-11280
URL: https://issues.apache.org/jira/browse/IGNITE-11280
Project: Ignite
Issue
Vladimir Ozerov created IGNITE-11278:
Summary: SQL: Extract query parsing into separate class
Key: IGNITE-11278
URL: https://issues.apache.org/jira/browse/IGNITE-11278
Project: Ignite
Vladimir Ozerov created IGNITE-11279:
Summary: SQL: Remove H2's "prepared" from DML plans
Key: IGNITE-11279
URL: https://issues.apache.org/jira/browse/IGNITE-11279
Project: Ignite
Vladimir Ozerov created IGNITE-11275:
Summary: SQL: Move all command processing stuff to DDL processor
Key: IGNITE-11275
URL: https://issues.apache.org/jira/browse/IGNITE-11275
Project: Ignite
Vladimir Ozerov created IGNITE-11274:
Summary: SQL: Make GridCacheSqlQuery immutable
Key: IGNITE-11274
URL: https://issues.apache.org/jira/browse/IGNITE-11274
Project: Ignite
Issue Type
Vladimir Ozerov created IGNITE-11231:
Summary: SQL: Remove scan index for merge table
Key: IGNITE-11231
URL: https://issues.apache.org/jira/browse/IGNITE-11231
Project: Ignite
Issue Type
Vladimir Ozerov created IGNITE-11227:
Summary: SQL: Streamline DML execution logic
Key: IGNITE-11227
URL: https://issues.apache.org/jira/browse/IGNITE-11227
Project: Ignite
Issue Type
Vladimir Ozerov created IGNITE-11226:
Summary: SQL: Remove GridQueryIndexing.prepareNativeStatement
Key: IGNITE-11226
URL: https://issues.apache.org/jira/browse/IGNITE-11226
Project: Ignite
Vladimir Ozerov created IGNITE-11223:
Summary: SQL: Merge "collectCacheIds" and "processCaches" methods
Key: IGNITE-11223
URL: https://issues.apache.org/jira/browse/IGNITE-11223
Vladimir Ozerov created IGNITE-11212:
Summary: SQL: Merge affinity collocation models for partition
pruning and distributed joins
Key: IGNITE-11212
URL: https://issues.apache.org/jira/browse/IGNITE-11212
Vladimir Ozerov created IGNITE-11211:
Summary: SQL: Rework connection pool
Key: IGNITE-11211
URL: https://issues.apache.org/jira/browse/IGNITE-11211
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11210:
Summary: SQL: Introduce common logical execution plan for all
query types
Key: IGNITE-11210
URL: https://issues.apache.org/jira/browse/IGNITE-11210
Project
Vladimir Ozerov created IGNITE-11208:
Summary: SQL: Move reservations from QueryContext to MapQueryResult
Key: IGNITE-11208
URL: https://issues.apache.org/jira/browse/IGNITE-11208
Project: Ignite
Vladimir Ozerov created IGNITE-11209:
Summary: SQL: streamline DML execution logic
Key: IGNITE-11209
URL: https://issues.apache.org/jira/browse/IGNITE-11209
Project: Ignite
Issue Type
Vladimir Ozerov created IGNITE-11207:
Summary: SQL: Remove MapNodeResults class
Key: IGNITE-11207
URL: https://issues.apache.org/jira/browse/IGNITE-11207
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11206:
Summary: SQL: Merge execution flow for local and map queries
Key: IGNITE-11206
URL: https://issues.apache.org/jira/browse/IGNITE-11206
Project: Ignite
Vladimir Ozerov created IGNITE-11203:
Summary: SQL: global refactoring
Key: IGNITE-11203
URL: https://issues.apache.org/jira/browse/IGNITE-11203
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-11202:
Summary: SQL: Move partition reservation logic to separate class
Key: IGNITE-11202
URL: https://issues.apache.org/jira/browse/IGNITE-11202
Project: Ignite
Vladimir Ozerov created IGNITE-11200:
Summary: SQL: query contexts should not be static
Key: IGNITE-11200
URL: https://issues.apache.org/jira/browse/IGNITE-11200
Project: Ignite
Issue
Best Regards,
> Igor
>
>
> On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov
> wrote:
>
> > Igor,
> >
> > Yes, cache groups are public API. However, we try to avoid new APIs
> > depending on them.
> > The main point from my side is that “similar cache
is a public thing [1].
>
> [1] - https://apacheignite.readme.io/docs/cache-groups
>
> Best Regards,
> Igor
>
>
> On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov
> wrote:
>
> > Pavel, Igor,
> >
> > This is not very accurate to say that this will not save
Vladimir Ozerov created IGNITE-11185:
Summary: SQL: Move distributed joins code from base index to
H2TreeIndex
Key: IGNITE-11185
URL: https://issues.apache.org/jira/browse/IGNITE-11185
Project
add flag to every response, that shows
> whether
> > >> the
> > >> > > Affinity Topology Version of the cluster has changed since the
> last
> > >> > request
> > >> > > from the client.
> > >> > > I propose to keep this
Vladimir Ozerov created IGNITE-11180:
Summary: SQL: give more sensible names to reducer classes
Key: IGNITE-11180
URL: https://issues.apache.org/jira/browse/IGNITE-11180
Project: Ignite
Vladimir Ozerov created IGNITE-11169:
Summary: SQL: Remove collocation model-related code from
GridH2QueryContext
Key: IGNITE-11169
URL: https://issues.apache.org/jira/browse/IGNITE-11169
Project
Vladimir Ozerov created IGNITE-11160:
Summary: SQL: Create light-weight row for read-only rows
Key: IGNITE-11160
URL: https://issues.apache.org/jira/browse/IGNITE-11160
Project: Ignite
ounds like the node is experiencing big troubles and it might be
> > better just to shut it down completely.
> >
> > -
> > Denis
> >
> >
> > On Tue, Jan 15, 2019 at 8:00 AM Юрий
> wrote:
> >
> >> Denis and other Ignit
Vladimir Ozerov created IGNITE-11134:
Summary: SQL: Do not wrap key and value objects in
GridH2KeyValueRowOnheap
Key: IGNITE-11134
URL: https://issues.apache.org/jira/browse/IGNITE-11134
Project
Vladimir Ozerov created IGNITE-8:
Summary: SQL: Ability to resolve partition from argument without H2
Key: IGNITE-8
URL: https://issues.apache.org/jira/browse/IGNITE-8
Project: Ignite
Vladimir Ozerov created IGNITE-7:
Summary: SQL: Move partition nodes to core module
Key: IGNITE-7
URL: https://issues.apache.org/jira/browse/IGNITE-7
Project: Ignite
Issue
Vladimir Ozerov created IGNITE-5:
Summary: Binary: rework thread-local binary context to avoid set()
operation
Key: IGNITE-5
URL: https://issues.apache.org/jira/browse/IGNITE-5
Hi Steve,
H2 cannot be removed from Ignite easily as it is integrated pretty deep
into indexing module. Good news is that our usage of H2 is pretty limited -
we only use it's parser, planner and execution pipeline. We do not use H2
as data storage.
Please let me know if you need any additional cla
h column order from the columns view. For
> example you want to know which columns are indexed already. In case we will
> have plain comma-separated form it can't be achieved.
>
>
>
>
>
> чт, 24 янв. 2019 г. в 18:09, Vladimir Ozerov :
>
> > Hi Yuriy,
> >
>
gy and affinity versions, but motivation here
> is not that clear for me to be honest.
>
> I think that the most common approach with single incrementing version
> is much simpler then several counters and I would prefer to leave it that
> way.
>
>
> пт, 25 янв. 2019 г. в 16
Ivan,
The change you describe is extremely valuable thing as it allows to detect
changes into global configuration which is of great importance for SQL.
Will topology and affinity changes be reflected in metastore history as
well? From SQL perspective it is important for us to be able to understan
Vladimir Ozerov created IGNITE-11083:
Summary: SQL: Extract query model from splitter
Key: IGNITE-11083
URL: https://issues.apache.org/jira/browse/IGNITE-11083
Project: Ignite
Issue Type
n (ex. -1 equal to endless waiting) and so on, but
> in our case we want to disable whole functionality rather than change
> parameter value.
>
> --
> Best regards,
> Anton Kalashnikov
>
>
> 24.01.2019, 22:03, "Vladimir Ozerov" :
> > Hi Anton,
> >
&
Hi Anton,
This is great feature, but I am a bit confused about automatic disabling of
a feature during manual baseline adjustment. This may lead to unpleasant
situations when a user enabled auto-adjustment, then re-adjusted it
manually somehow (e.g. from some previously created script) so that
aut
Hi Yuriy,
Please note that MySQL link is about SHOW command, which is a different
beast. In general I think that PG approach is better as it allows user to
get quick overview of index content without complex JOINs. I would start
with plain single view and add columns view later if we found it usef
Vladimir Ozerov created IGNITE-11057:
Summary: Document new SQL system view "CACHE_GROUPS_IO"
Key: IGNITE-11057
URL: https://issues.apache.org/jira/browse/IGNITE-11057
Proje
Vladimir Ozerov created IGNITE-11042:
Summary: Document new SQL system view "TABLES"
Key: IGNITE-11042
URL: https://issues.apache.org/jira/browse/IGNITE-11042
Project: Ignite
ven a partition. So I think it wouldn’t require any
> cross-node ordering.
>
> Thank you,
>
> Piotr
>
> śr., 9 sty 2019, 21:11: Vladimir Ozerov napisał(a):
>
> > Hi,
> >
> > MVCC caches have the same ordering guarantees as non-MVCC caches, i.e.
> two
> &
try to retrieve and getting null.
> > Therefore, I suppose switching client to server defaults is what has to
> be
> > done. If the user decides to switch to full schema mode, at least he/she
> > will be aware of it. And for deserialization, the schema will be
> retri
Vladimir Ozerov created IGNITE-10986:
Summary: SQL: Drop _VER field support
Key: IGNITE-10986
URL: https://issues.apache.org/jira/browse/IGNITE-10986
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-10985:
Summary: SQL: create low-overhead implementation of Row for SELECTs
Key: IGNITE-10985
URL: https://issues.apache.org/jira/browse/IGNITE-10985
Project: Ignite
"Compact footer" is optimization which saves a lot of space. Object
serialized in this form do not have the full information required for
deserialization. Metadata necessary for deserialization (aka "schema") is
located on cluster nodes. For this client it could be requested through
special command
Vladimir Ozerov created IGNITE-10971:
Summary: SQL: Support partition pruning for distributed joins
Key: IGNITE-10971
URL: https://issues.apache.org/jira/browse/IGNITE-10971
Project: Ignite
1 - 100 of 2411 matches
Mail list logo
