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