You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@ignite.apache.org by joseheitor <jo...@heitorprojects.com> on 2019/05/09 05:48:51 UTC

Re: H2 SQL query optimiser strategy in Ignite

Hi Ignite Team,

Have the system architects explored the option of maintaining table
statistics on each node (as Postgres and other legacy SQL engines do), and
then distributing the raw SQL query to each node and letting each node
execute the query planner locally, optimising the query based on the
statistics on hand for the given node...?

Would this not optimise overall performance of the query, and eliminate the
need for developers and DBAs to have try to guess the optimum JOIN order?
(which may in fact vary on each node...?)

Thanks,
Jose



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: H2 SQL query optimiser strategy in Ignite

Posted by Ivan Pavlukhina <vo...@gmail.com>.

Hi Jose,

Yes cost-based optimization of query fragments executed locally on nodes using local node statistics sounds as a good idea. Also there might be other options. Unfortunately neither was implemented yet in Ignite.

Sent from my iPhone

> On 9 May 2019, at 08:48, joseheitor <jo...@heitorprojects.com> wrote:
> 
> Hi Ignite Team,
> 
> Have the system architects explored the option of maintaining table
> statistics on each node (as Postgres and other legacy SQL engines do), and
> then distributing the raw SQL query to each node and letting each node
> execute the query planner locally, optimising the query based on the
> statistics on hand for the given node...?
> 
> Would this not optimise overall performance of the query, and eliminate the
> need for developers and DBAs to have try to guess the optimum JOIN order?
> (which may in fact vary on each node...?)
> 
> Thanks,
> Jose
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/