Hi Igor!
IMO we need to maintain the backward compatibility between old and new
query engines as much as possible. And therefore we shouldn't change the
behavior of local queries.
So, for local queries Calcite's planner shouldn't consider the
distribution trait at all.
--
Kind Regards
Roman Kondakov
On 01.11.2019 17:07, Seliverstov Igor wrote:
Hi Igniters,
Working on new generation of Ignite SQL I faced a question: «Do we need local
queries at all and, if so, what semantic they should have?».
Current planing flow consists of next steps:
1) Parsing SQL to AST
2) Validating AST (against Schema)
3) Optimizing (Building execution graph)
4) Splitting (into query fragments which executes on target nodes)
5) Mapping (query fragments to nodes/partitions)
At last step we check that all Fragment sources (a table or result) have the
same distribution (in other words all sources have to be co-located)
Planner and Splitter guarantee that all caches in a Fragment are co-located, an
Exchange is produced otherwise. But if we force local execution we cannot
produce Exchanges, that means we may face two non-co-located caches inside a
single query fragment (result of local query planning is a single query
fragment). So, we cannot pass the check.
Should we throw an exception or omit the check for local query planning or
prohibit local queries at all?
Your thoughts?
Regards,
Igor
