SQL on changing topology

[Alexey Goncharuk]

Igniters,

I've got another idea for SQL queries on changing topology. Why do we need
to reserve partitions while we already have an ability to snapshot indexes
and query data against that snapshot anyway? All we need to do is to get a
partition map state together with index snapshot and then query correct
partitions.

We eliminate partition reservation at all which should be faster in my view.

Thoughts?
--AG

[yzhdanov]

We need to make sure that partition is in the OWNING state on the node
processing the request. I don't see how your approach guarantees that.

--Yakov

2015-05-12 17:10 GMT+03:00 Alexey Goncharuk <[hidden email]>:

> Igniters,
>
> I've got another idea for SQL queries on changing topology. Why do we need
> to reserve partitions while we already have an ability to snapshot indexes
> and query data against that snapshot anyway? All we need to do is to get a
> partition map state together with index snapshot and then query correct
> partitions.
>
> We eliminate partition reservation at all which should be faster in my
> view.
>
> Thoughts?
> --AG
>

[Sergi]

Yes, we need to make sure that we will not get index snapshot in any random
state.

Sergi

2015-05-12 20:29 GMT+03:00 Yakov Zhdanov <[hidden email]>:

> We need to make sure that partition is in the OWNING state on the node
> processing the request. I don't see how your approach guarantees that.
>
> --Yakov
>
> 2015-05-12 17:10 GMT+03:00 Alexey Goncharuk <[hidden email]>:
>
> > Igniters,
> >
> > I've got another idea for SQL queries on changing topology. Why do we
> need
> > to reserve partitions while we already have an ability to snapshot
> indexes
> > and query data against that snapshot anyway? All we need to do is to get
> a
> > partition map state together with index snapshot and then query correct
> > partitions.
> >
> > We eliminate partition reservation at all which should be faster in my
> > view.
> >
> > Thoughts?
> > --AG
> >
>