IGNITE-5468 ticket description looks confusing.

[Andrew Mashenkov]

Guys,

We have a ticket that is implemented, but the ticket itseft and the
solution looks confusing as ticket title is differs to its description:
"IGNITE-5468: Need to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE on per query
basis" [1]


Seems, initially, we want to have ability to change these 2 parameters  as
on per-query basis as its defaults.

Having defaults in cache configuration is error prone as we can run same
query on different caches with different defaults.
With this approach we will get confused if same query will work fine with
one cache and fails with OOME on another.
Furthermore, we have a plans to move sql configuration options out from
cache configuration in future releases.

Lets introduce additional options in SqlQuery and SqlFieldsQuery classes
and leave CacheConfiguration without changes.

Thus,
*there will no need to pass cache context to methods and classes increasing
code complexity.
*end user will have ability to tune every single query.
*avoid confusing situation with running same query on different caches.


Thoughts?

[1] https://issues.apache.org/jira/browse/IGNITE-5468

--
Best regards,
Andrey V. Mashenkov

[Vitaliy Biryukov]

Andrew Mashenkov wrote

Thus,
*there will no need to pass cache context to methods and classes increasing
code complexity.
*end user will have ability to tune every single query.
*avoid confusing situation with running same query on different caches.

To satisfy all these points, I need to add these 2 parameters into Query class.

[dsetrakyan]

Yakov,

Since you filed this ticket, can you please comment?

D.

On Tue, Jul 4, 2017 at 6:47 AM, Vitaliy Biryukov <
[hidden email]> wrote:

> Andrew Mashenkov wrote
> > Thus,
> > *there will no need to pass cache context to methods and classes
> > increasing
> > code complexity.
> > *end user will have ability to tune every single query.
> > *avoid confusing situation with running same query on different caches.
>
> To satisfy all these points, I need to add these 2 parameters into Query
> class.
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/IGNITE-5468-ticket-
> description-looks-confusing-tp19436p19438.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>

[yzhdanov]

Same query against different caches? This sounds like same query against
different tables. :) Andrey can you please provide real-world example?

What 2 params do you mean? Which one is the second?

My points are:
- provide ability to set limits without restarting the cluster.
- provide ability to set limits per query as different queries may require
different resources and having one hard limit for all the queries seems to
be very inconvenient.

Ideally, I would get rid of this IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
and use just memory limits - if query runs out of memory then it is
cancelled with proper error message, but I doubt if this can be done
quickly.

--
Yakov Zhdanov

[Andrew Mashenkov]

Yes, Yakov. I mean query with join of 2 caches can be run on either of it.

Second parameter is merge prefetch size. You can see they going together in
PR.

5 июля 2017 г. 11:48 пользователь "Yakov Zhdanov" <[hidden email]>
написал:

> Same query against different caches? This sounds like same query against
> different tables. :) Andrey can you please provide real-world example?
>
> What 2 params do you mean? Which one is the second?
>
> My points are:
> - provide ability to set limits without restarting the cluster.
> - provide ability to set limits per query as different queries may require
> different resources and having one hard limit for all the queries seems to
> be very inconvenient.
>
> Ideally, I would get rid of this IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
> and use just memory limits - if query runs out of memory then it is
> cancelled with proper error message, but I doubt if this can be done
> quickly.
>
> --
> Yakov Zhdanov
>

[yzhdanov]

Let me review when I am back next week.

--
Yakov Zhdanov