Hi Maksim, Nice idea, I'd like to see this feature in Ignite. The motivation is clear to me, it would be nice to have fast scans and omit SQL overhead on planning, parsing and etc in some simple use-cases.
I've left few minor comments to the IEP, but I have the next questions which answer I failed to find in IEP. 1. Is it possible to extend ScanQuery functionality to pass index condition as a hint/parameter rather than create a separate query type? This allows a user to run a query over the particular table (for multi-table per cache case) and use an index for some type of conditions. 2. Functional indices, as you wrote, should use Functions distributed via peerClassLoading mechanics. This means there will no class with function on server sides and such classes are not persistent. Seems, they can survive grid restart. This task looks like a huge one because the lifecycle of such classes should be described first. Possible pitfalls are: * Durability. Function code MUST be persistent, to survive node restart as there can be no guaranteed classes available on the server-side. * Consistency. Server (and maybe clients) nodes MUST have the same class code at a time. * Code ownership. Would class code be shared or per-cache? If first, you can't just change class code by loading a new one, because other caches may use this function. If second, different caches may have different code/behavior, that may be non-obvious to end-user. 3. IndexScan by the predicate is questionable. Maybe it will can faster if there are multiple tables in a cache, but looks similar to ScanQuery with a filter. Also, I believe we can have a common API (configuring, creating, using) for all types of Indices, but some types (e.g. functional) will be ignored in SQL due to limited support on H2 side, and other types will be shared and could be used by ScanQuery engine as well as by SQL engine. On Tue, Apr 6, 2021 at 4:14 PM Maksim Timonin <timonin.ma...@gmail.com> wrote: > Hi, Igniters! > > I'd like to propose a new feature - opportunity to query and create indexes > from public API. > > It will help in some cases, where: > 1. SQL is not applicable by design of user application; > 2. Where IndexScan is preferable than ScanQuery for performance reasons; > 3. Functional indexes are required. > > Also it'll be great to have a transactional support for such queries, like > the "select for update" query provides. But I don't dig there much. It will > be a next step if this API will be implemented. > > I've prepared an IEP-71 for that [1] with more details. Please share your > thoughts. > > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-71+Public+API+for+secondary+index+search > -- Best regards, Andrey V. Mashenkov
