Hello! 1. H2 does not store data but, as far as my understanding goes, it created SQL indexes from data. Ignite feeds H2 rows that it asks for, and H2 creates indexes on them and executes queries on them. 2. Ignite always has special index on your key (since it's a key-value storage it can always find tuple by key). Ignite is also aware of key's hash code, and affinity key value always maps to one partition of data (of 1024 by default). Those are not H2 indexes and they're mostly used on planning stage. E.g. you can map query to one node if affinity key is present in the request. 3. Data is brought onto the heap to read any fields from row. GROUP BY will hold its tuples on heap. Ignite has configurable index inlining where you can avoid reading objects from heap just to access indexed fields. 4. With GROUP BY, lazy evaluation will not help you much. It will still have to hold all data on heap at some point. Lazy evaluation mostly helps with "SELECT * FROM table" type queries which provide very large and boring result set.
Hope this helps. -- Ilya Kasnacheev пт, 14 сент. 2018 г. в 17:39, eugene miretsky <eugene.miret...@gmail.com>: > Hello, > > Trying to understand how exactly SQL queries are executed in Ignite. A few > questions > > > 1. To what extent is H2 used? Does it store the data? Does it create > the indexes? Is it used only for generating execution plans? I believe that > all the data used to be stored in H2, but with the new durable memory > architecture, I believe that's no longer the case. > 2. Which indexes are used? Ignite creates B+ tree indexes and stores > them in Index pages, but I also see AFFINITY_KEY, _key_PK and _key_PK_hash > indexes created in H2. > 3. When is data brought onto the heap? I am assuming that groupby and > aggregate require all the matching queries to first be copied from off-heap > to heap > 4. How does lazy evaluation work? For example, for group_by, does it > bring batches of matching records with the same group_by key onto the heap? > > I am not necessarily looking for the exact answers, but rather pointer in > the right direction (documentation, code, jiras) > > Cheers, > Eugene >
