I've done with splitting indices: distributed joins has been fixed, issues
with prepared statements cache has been disappear.
Ticket Ignite-4106 [1] is ready for review.
[1] https://issues.apache.org/jira/browse/IGNITE-4106
On Mon, Dec 5, 2016 at 3:16 PM, Sergi Vladykin
wrote:
> I'd prefer to a
I'd prefer to avoid merging ranges from index segments, it is a huge
performance penalty.
I thought a bit more: why would one configure a different level of query
parallelism on different caches? I don't see any sane reason for this. Most
probably it will be a number of CPU cores on the box or som
Copy from Review comment
>Sergi: Another thing is how we will handle case if different caches in
join have different parallelism level?
Good question, Sergi. It seems we can't handle it.
I've a crazy idea and not sure it is workable.
What if we would split indices to power of 2 number of segments
Cool! I'll take a look today.
Sergi
2016-11-30 18:23 GMT+03:00 Andrey Mashenkov :
> Serj, you can see a PR attached to jira issue [1], that can be opened with
> upsource [2].
>
> Tanks, I remember about distributed queries and wiil rework them right
> after we come to agreemant that the solutio
Serj, you can see a PR attached to jira issue [1], that can be opened with
upsource [2].
Tanks, I remember about distributed queries and wiil rework them right
after we come to agreemant that the solution for simple queries is ok.
[1] https://issues.apache.org/jira/browse/IGNITE-4106
[2] http://
Per cache SQL parallelism level looks reasonable to me here.
I'm not sure what do you mean about "prepared statement cache is useless
with splitted indices", most probably you parallelize queries in some wrong
way if this is true.
Also do not forget about distributed joins: with parallel queries
It looks like we can't just split sql query to several threads due to H2
limitations.
We can bound query thread with certain set of partitions, but, actually, H2
will read whole index and then filter entries regarding its partition. So,
we can get significant speed-up that way.
Unfortunatelly, H2
Completely agree, great point!
On Sun, Oct 30, 2016 at 9:17 AM, Sergi Vladykin
wrote:
> I think it must be a maximum local parallelism level but not just `on` and
> `off` setting (the default is obviously 1). This along with separately
> configurable query thread pool will give a finer grained c
I think it must be a maximum local parallelism level but not just `on` and
`off` setting (the default is obviously 1). This along with separately
configurable query thread pool will give a finer grained control over
resources.
Sergi
2016-10-30 18:22 GMT+03:00 Dmitriy Setrakyan :
> I already ment
I already mentioned this in another email, but we should be able to turn
this property on and off on per-query and per-cache levels.
On Sat, Oct 29, 2016 at 11:45 AM, Sergi Vladykin
wrote:
> Agree, lets implement such a parallelization.
>
> I think we will need an explicit setting for SqlQuery a
Agree, lets implement such a parallelization.
I think we will need an explicit setting for SqlQuery and SqlFieldsQuery,
the default behavior should not change.
Sergi
2016-10-28 22:39 GMT+03:00 Andrey Mashenkov :
> So, now we have every SQL query run on each node in single thread. This can
> be
I am OK, as long as we have ability to turn this behavior one and off on
per-query and per-cache basis.
On Fri, Oct 28, 2016 at 12:43 PM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:
> So, now we have every SQL query run on each node in single thread. This can
> be an issue for heavy que
12 matches
Mail list logo
