On Mon, Jan 23, 2017 at 11:16 AM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> Dmitriy,
>
> This still can make sense for some scenarios, because we could limit number
> of initial map requests reducing overall query overhead.
>
> Are you still sure we need to throw an exception ?
>
Dmitriy,
This still can make sense for some scenarios, because we could limit number
of initial map requests reducing overall query overhead.
Are you still sure we need to throw an exception ?
2017-01-23 1:49 GMT+03:00 Dmitriy Setrakyan :
> On Sun, Jan 22, 2017 at 5:06
On Sun, Jan 22, 2017 at 5:06 AM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> Yes, it will be possible because distributed joins are executed using
> broadcast queries.
>
>
In this case why even bother supporting non-collocated joins? We need to
throw an exception in this case.
Yes, it will be possible because distributed joins are executed using
broadcast queries.
2017-01-22 15:49 GMT+03:00 Dmitriy Setrakyan :
> On Sun, Jan 22, 2017 at 4:46 AM, Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
>
> > Dmitriy,
> >
> > ScanQueries
On Sun, Jan 22, 2017 at 4:46 AM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> Dmitriy,
>
> ScanQueries currently support only one partition. I will extend it to
> support multiple partitions.
>
> For distributed joins partitions will only be applied on "map" query step.
>
Will it
Dmitriy,
ScanQueries currently support only one partition. I will extend it to
support multiple partitions.
For distributed joins partitions will only be applied on "map" query step.
2017-01-21 21:19 GMT+03:00 Dmitriy Setrakyan :
> On Sat, Jan 21, 2017 at 1:53 AM, Alexei
On Sat, Jan 21, 2017 at 1:53 AM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> >> > > > 5. I have the same understanding. Distributed joins will ignore
> the
> >> > > > setting.
> >> > > > This is not implemented yet..
> >> > > >
> >> > >
> >> > > And again, this will be very
BTW, I still need SQL queries part review.
2017-01-21 12:52 GMT+03:00 Alexei Scherbakov :
>
>
> 2017-01-20 20:31 GMT+03:00 Dmitriy Setrakyan :
>
>> On Fri, Jan 20, 2017 at 7:00 AM, Alexei Scherbakov <
>> alexey.scherbak...@gmail.com> wrote:
>>
2017-01-20 20:31 GMT+03:00 Dmitriy Setrakyan :
> On Fri, Jan 20, 2017 at 7:00 AM, Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
>
> > Dmitriy,
> >
> > Honestly, I don't understand your issues with a reviewing, because I've
> > provided PR link in the JIRA
On Fri, Jan 20, 2017 at 7:00 AM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> Dmitriy,
>
> Honestly, I don't understand your issues with a reviewing, because I've
> provided PR link in the JIRA ticket.
>
> Just open it in browser and enjoy :)
>
> Nevertheless, I've added short
Dmitriy,
Honestly, I don't understand your issues with a reviewing, because I've
provided PR link in the JIRA ticket.
Just open it in browser and enjoy :)
Nevertheless, I've added short description for API changes in the JIRA
ticket.
Other comments are below.
2017-01-19 20:35 GMT+03:00
Alexey S,
My comments are below. I would like to ask you again to provide all the API
changes explicitly in the Jira ticket without asking the community to
download the whole GIT repo.
D.
On Thu, Jan 19, 2017 at 6:27 AM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> 1. OK.
>
Vladimir, do you have any idea how specific partition settings will work
for queries over replicated caches, when every node will have full data
set. ?
The query will only be parallelized on nodes defined by passed partitions,
or something else ?
2017-01-19 17:27 GMT+03:00 Alexei Scherbakov
1. OK.
2. Agreed. In future we might split query execution between nodes, but for
now query is routed to random node in grid,
3. OK, let's mark getter/setter as deprecated.
4. Query must be executed locally only for defined partitions. Currently
this setting is ignored for local queries.
5. I
Agree, lets remove everything related to partition ranges. Looks like
unnecessary complication.
Sergi
2017-01-19 10:01 GMT+03:00 Vladimir Ozerov :
> Several side notes about API.
>
> 1) I would avoid ranges even in this form.for the sake of simplicity.
> Ignite do not have
Several side notes about API.
1) I would avoid ranges even in this form.for the sake of simplicity.
Ignite do not have any notion of "partition range" in affinity API, so I do
not understand how users are going to work on ranges unless they have some
very special custom affinity function, which
I mean distributed joins.
2017-01-19 0:10 GMT+03:00 Alexei Scherbakov :
> Guys,
>
> I've finished adding API changes and implemented proper nodes routing.
>
> Currently it doesn't work with distributed queries.But I think this
> feature should be compatible with it.
Guys,
I've finished adding API changes and implemented proper nodes routing.
Currently it doesn't work with distributed queries.But I think this feature
should be compatible with it.
Could anyone take a look at current branch state while I'm looking deeper
into dsitributed queries code?
Issue:
OK, let's do it this way.
2017-01-13 13:27 GMT+03:00 Sergi Vladykin :
> Internally we still use int[] when we send partitions (see
> GridH2QueryRequest.parts). It looks like we only do more work with
> PartitionSet.
>
> I like the idea of bitset for partitions, but
Internally we still use int[] when we send partitions (see
GridH2QueryRequest.parts). It looks like we only do more work with
PartitionSet.
I like the idea of bitset for partitions, but
1. We have to change internals first to use it, otherwise the optimization
makes no sense.
2. We will need to
PartitionSet hides internal implementation of int array.
This allows as to efficiently represent contiguous range of partitions and
defines clear API for ordered iteration over partitions and containment
check.
Even better to go with compressed bitmap, as I mentioned in ticket comment.
This will
On Thu, Jan 12, 2017 at 6:12 AM, Sergi Vladykin
wrote:
> I looked at the code. The PartitionSet concept looks overengineered to me,
> why wouldn't we just go with int[]?
>
Agree.
>
> Sergi
>
> 2017-01-12 15:18 GMT+03:00 Alexei Scherbakov
I looked at the code. The PartitionSet concept looks overengineered to me,
why wouldn't we just go with int[]?
Sergi
2017-01-12 15:18 GMT+03:00 Alexei Scherbakov :
> Done.
>
> 2017-01-11 20:39 GMT+03:00 Dmitriy Setrakyan :
>
> > Alexey,
> >
>
Done.
2017-01-11 20:39 GMT+03:00 Dmitriy Setrakyan :
> Alexey,
>
> I am not sure I am seeing the API changes documented in the ticket. Can you
> please either document them or add GIT links for the new classes?
>
> D.
>
> On Wed, Jan 11, 2017 at 9:29 AM, Alexei Scherbakov
Alexey,
I am not sure I am seeing the API changes documented in the ticket. Can you
please either document them or add GIT links for the new classes?
D.
On Wed, Jan 11, 2017 at 9:29 AM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> Guys,
>
> I've just submitted a PR for
>
25 matches
Mail list logo