maria-developers team mailing list archive

[Igor Babaev <igor@xxxxxxxxxxxx>]

Hi Sergey,

I looked through your code trying to figure out in what direction you
are moving. If my understanding of the code is correct you move in the
right direction.

Here are some general notes.
Ideally I would like to see the following architecture (I ignore here
the fact that we have to support SHOW EXPLAIN, because I don't
understand yet the principles your implementation is based on).

For any SELECT/UPDATE/DELETE/INSERT statement:

1. The optimizer builds a structure that could be called ABSTRACT QUERY
EXECUTION PLAN (AQEP)

2. AQEP contains/ has an access to all info to build:
   a) executed code for this AQEP
   or/and
   b) explain for this AQEP

3. When we build the explain for am AQEP we generate a tree structure
each node of which contains a compact representation of a row in the
external linear representation of the EXPLAIN tree. The external
representation can be in different formats.

4. AQEPs for statements of different types can belong to different
classes. Yet, I would prefer them to be derived from the same base class
(directly or indirectly)

5. I don't think that the internal representations of an explain row (a
node from the explain tree) should belong to different classes though.

6. It's ok if a AQEP contains some info not used for explain.
Still the structures that definitely are parts of the executed code are
not desirable there.

Let me know if something is not clear for you and you are not sure how
you should proceed with EXPLAIN for UPDATE.

Regards,
Igor.


On 12/17/2012 11:49 PM, Sergei Petrunia wrote:
> Hello Igor,
> 
> Hello Igor, 
> 
> Could you please review the following two patches:
> 
> http://lists.askmonty.org/pipermail/commits/2012-December/003944.html
> http://lists.askmonty.org/pipermail/commits/2012-December/003945.html
> 
> I think they implement the ideas about MDEV-3798 we've discussed earlier.
> 
> BR
>  Sergei