Dima,
I filed a ticket [1]. This is very promising approach which will allow us
to replace regular joins with nested tables in many cases, thus boosting
performance of JOINs and making Ignite's affinity configuration easier form
UX perspecitve. But this is a big thing, as it would require fully-fl
Thanks, Vladimir, got it. However, even though we may have different
indexes, the data should be on the same node, if it is properly collocated.
I do agree that we should try to remove extra index lookups, if possible.
Do we have a ticket for it? Is it a lot of work?
D.
On Wed, Oct 25, 2017 at 3:
For example, currently every table in Ignite has at least two PK indexes -
one for cache operations, and another one for H2. If you have two tables
(parent - child), you have either 4 indexes (if they are in different
groups), or 3 indexes (same logical group). But even if certain tree is
shared be
In Spanner once parent key is found you don't need to search for child keys
from scratch - they are located just after the parent key in the tree. In
Ignite child and parent keys are located in different trees, hence more
lookups are needed.
On Wed, Oct 25, 2017 at 1:36 PM, Dmitriy Setrakyan
wrot
On Wed, Oct 25, 2017 at 3:32 AM, Vladimir Ozerov
wrote:
> Dima,
>
> Yes, I saw it also. But this is not about syntax only. Spanner use this
> information to store data efficiently - child entries a located near to
> their parents. We can think of it as if all related tables were logical
> caches
Dima,
Yes, I saw it also. But this is not about syntax only. Spanner use this
information to store data efficiently - child entries a located near to
their parents. We can think of it as if all related tables were logical
caches inside one physical cache, sorted by the key. With this storage
forma
Igniters,
Please take a look at how the affinity syntax works in Google Spanner:
https://stackoverflow.com/questions/46903159/can-i-have-
multiple-tables-with-same-parent-in-google-spanner
I find it rather nice. Perhaps we can borrow from it.
D.
