Hi!
Sorry for the late reply.
Pushing complete joins is harder since tables are horizontally
fragmented over the data nodes. Data nodes currently only support
executing conditions on data stored locally in one data node, all
collection of data from several data nodes is done in the SQL nodes.
We do plan to improve join performance by better use of the parallel
execution support in the internal interface to the data nodes. This will
also include repetitive pushing the join conditions (after substituting the
result from scanning outer table).
BR
-- Martin
PeterB.Volk@stripped wrote:
>Hey,
>
>thanks for your reply. I actuallz meant the MySql<->Node communication.
>
>So according to your additional comments the Interface does allow to push
>the where or part of the where condition clause through to the storage
>engine and the Clusternodes handle the where clause to reduce the amount of
>data that is transfered between Server and node. Right? Are there any plans
>to actually push any thing else down to the storage engine? Because it this
>could be used in a join between several NDB tables that reside on the same
>node that the node itself executes the join. If this then is done on all
>nodes there could be a great performance win since the join is executed in
>paralell.
>
>Peter
>
>
>
>>--- Ursprüngliche Nachricht ---
>>Von: Martin Skold <Martin.Skold@stripped>
>>An: Sergei Golubchik <serg@stripped>
>>Kopie: "Peter B. Volk" <PeterB.Volk@stripped>, internals@stripped
>>Betreff: Re: Query execution
>>Datum: Fri, 24 Feb 2006 09:52:00 +0100
>>
>>Hi!
>>
>>One comment on answer to question three (se below).
>>
>>BR
>>-- Martin
>>
>>Sergei Golubchik wrote:
>>
>>
>>
>>>Hi!
>>>
>>>On Feb 14, Peter B. Volk wrote:
>>>
>>>
>>>
>>>
>>>>Hello all,
>>>>
>>>>I've looking at the source code a bit and have a few questions:
>>>>
>>>>1. As far as I'Ve seen the optimizer chooses the optimal plan and then
>>>>"sends" it to a virtual maschine that executes the plan ontop of the
>>>>storage engine and only hands very few primitives to the storage
>>>>engine. Right?
>>>>
>>>>
>>>>
>>>>
>>>Yes.
>>>
>>>
>>>
>>>
>>>
>>>>2. if so would it be possible send complete joins into the storage
>>>>engine? What would that have for an effect? Well a storage engine
>>>>could distribute the join to several different servers. Instead of
>>>>joining the data on the local server the remote servers could do
>>>>something like partial joins. This option would be something like a
>>>>grid.
>>>>
>>>>
>>>>
>>>>
>>>so far it's not possible. it's not even planned.
>>>It would be a nice feature, but it's quite complex, and we all have
>>>something to do already, so at the moment it is somewhere in the
>>>undefined future :(
>>>
>>>
>>>
>>>
>>>
>>>>3. In a cluster setup do the servers within a data node schare the
>>>>load of one select statement or does one server handle the complete
>>>>select statement?
>>>>
>>>>
>>>>
>>>>
>>>One server handles the complete select statement.
>>>
>>>
>>>
>>>
>>Seems to be some confusion of terminology here. MySQL servers execute
>>on-top
>>of the data nodes in the layered architecture Client<->MySQL
>>server<->Data nodes
>>(these are separate processes possibly running on separate machines, but
>>don't have to).
>>There is no concept of servers "within" a data node.
>>One MySQL server handles the complete select statement (with the exception
>>that as of 5.0, with condition pushdown, part of the selection condition
>>can be
>>pushed down to the data nodes). If the select statement generates full
>>table or
>>index scans, these are executed in parallel on all data nodes where the
>>data is
>>partitioned. If the select only required one primary key lookup then one
>>data node
>>would perform that lookup (actually not totally true either since the
>>read operation
>>would go through the transaction coordinator which forwards the read
>>request to
>>where the data is stored, if that is one and the same data node, it is
>>only one node).
>>
>>
>>
>>>Regards,
>>>Sergei
>>>
>>>
>>>
>>>
>>>
>>--
>>Martin Sköld, Software Engineer
>>MySQL AB, www.mysql.com
>>Office: +46 (0)730 31 26 21
>>
>>
>>
>>
>>
>
>
>
--
Martin Sköld, Software Engineer
MySQL AB, www.mysql.com
Office: +46 (0)730 31 26 21
