db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Beyer <s4224...@mail.inf.tu-dresden.de>
Subject Query plan extraction
Date Thu, 09 Nov 2006 18:03:04 GMT
Hi Derby community,

a while ago I´ve posted some mails, which shortly introduced my 
extensions, which I`m developing during my thesis and which I want to 
contribute to the community. These extensions will extend Derby with 
kind of a persistent workload repository and a well-designed query plan 
extraction extension. Now, I´ve got some questions and I would like to 
know what the community thinks about them:

I`m planning to store the query plans in some kind of system explain 
tables. I´m currently designing the scheme for the tables and I want to 
know, if the community is interested in a more general solution.
1. More specifically I mean, should this explain functionality include 
the plans generated during compilation phase? If yes, should the user 
have the ability to specifiy the exact position when during compilation 
(ParseTree, BindTree, OptimizedTree)?
2. Should the scheme support compilation and execution plans (This would 
mean there must be a mapping from the node tree to the resultset tree 
and vice versa and the scheme has to be more generic)?
2b. Should the approach be oriented on DB2, where the user has the 
ability to switch between, only explain, execute and explain, just 
execute without explain?
3. Another approach would be to develop two decoupled solutions, one for 
the compilation plans and one for the execution plans. The first one 
stores NodeTrees and the second one ResultSetTrees? What do you think, 
does this make sense for you?
4. Should the extension follow general derby architecture 
(FactoryInterface and Implementation) and should it therefore be so 
generic, that for example the extraction of the plans into xml files 
will also be possible with the suggested approach?
5. Should the solution extend, replace or coexist together with the 
ResultSetStatistics facility?
6. Is there some information, which is available, or easily derivable 
from current information, which is interesting for some of you and is 
currently not printed out with the current implementation of the 
ResultSetStatistics?

Have you got further ideas regarding this or some similiar extension?

My current timetable is the following:
In some weeks (before end of november) I want to post a detailed 
concept, describing my extensions in full detail. After the feedback for 
this, I want to start with the development. At the end of the year, I 
want to have a working solution. In the new year, I want to run the 
derby test suites and a couple of performance impact measurements to 
test my solution and to improve the stability. After that I`ll post a 
new thread, providing my results.

Thank you for your feedback,

Felix Beyer



Mime
View raw message