Une approche pour l`optimisation des requêtes dirigée par la

Une approche pour l’optimisation des requêtes dirigée
par la réutilisation des plans d’exécution
Lamia SADEG
Ladjel BELLATRECHE
Laboratoire mathématiques appliquées
Ecole Militaire Polytechnique
Bordj El Bahri, Algérie
[email protected]
LISI
ENSMA
Université de Poitiers, France
[email protected]
Résumé— L’optimisation des requêtes constitue un volet
très important dans le domaine des bases de données, et
ce depuis plus d’une trentaine d’années. Etant un
problème NP–Complet, engendrant une lenteur dans la
phase d’optimisation pour des requêtes complexes, une
panoplie de solutions ont été proposées, mais aucune
solution globale satisfaisante n’existe à ce jour. Afin de
pallier à ce problème, une solution serait de décharger
l’optimiseur en réutilisant les plans qu’il aurait générés
pour des requêtes futures sur la base d’une fonction de
similarité, ce qui accélérera le processus d’optimisation.
Dans notre travail, la requête est modélisée sous forme
d’un graphe étiqueté, ce qui transforme le problème
d’appariement de requêtes en un problème
d’isomorphisme des graphes. Le graphe d’une nouvelle
requête sera comparé aux graphes résultants des plans
d’optimisation passés – afin de ne prendre en compte
que l’information utile –, en utilisant un modèle de coût.
Les tests effectués ont donné des résultats satisfaisants
en termes de temps et de qualité d’optimisation.
alloué à l’optimisation de requêtes, les SGBD actuels se
limitent à chercher un plan d’exécution dit satisfaisant et
donc non nécessairement optimal. Ainsi, l’efficacité du plan
dépend de la charge sur l’optimiseur au moment de
l’optimisation. Afin de pallier à ce problème, une solution
serait de décharger l’optimiseur en réutilisant des plans qu’il
aurait générés antérieurement sur la base d’une fonction de
similarité. Cela lui permettrait de travailler à son plus haut
niveau en proposant des plans de qualité, ce qui se
répercutera positivement lors de leur réutilisation pour des
requêtes non encore optimisées. Cette solution a déjà été
adoptée par quelques optimiseurs commerciaux (à l’exemple
d’Oracle), mais dans le cadre restreint de la similarité
syntaxique qui reste bien rigide. Ce problème a été
récemment abordé dans [9, 16] où les auteurs ne se basent
plus sur la ressemblance syntaxique mais plutôt sur d’autres
métriques incluant des informations se rapportant aussi bien
à la requête qu’aux tables impliquées, le tout formant des
vecteurs de requêtes.
Mots-clés; optimisation des requêtes; modèle de coût;
réutilisation des plans dexécution.
I.
Dans notre travail, nous abordons le problème de la
représentation, l’extraction et l’utilisation de l’information
nécessaire à la comparaison des requêtes. Pour ce faire, nous
agissons sur trois volets :
•
La représentation des requêtes par un graphe. Cette
représentation est très utilisée, notamment dans
l’optimisation des requêtes complexes [18] ainsi que
dans la phase de réécriture de requêtes [8]. Les
graphes ont pour avantage d’offrir une représentation
plus compacte et plus expressive de la requête.
•
L’extraction de l’information nécessaire à partir du
plan d’exécution des requêtes optimisées. Ceci
permet de ne comparer les requêtes que sur la base
des structures d’optimisation réellement utilisées lors
de l’exécution des requêtes précédentes.
•
L’utilisation d’un modèle de coût permettant
d’établir la similarité entre les requêtes.
INTRODUCTION
L’optimisation des requêtes est un volet très important
dans le domaine des bases de données. Elle constitue une
étape inévitable dans le processus précédant l’exécution
d’une requête. Elle vise à ordonnancer de façon optimale les
actions impliquées dans une requête, en incluant les
structures d’optimisation requises pour une exécution en un
temps minimum. Cet ordonnancement, dit plan d’exécution,
est accompli en pratique par un module appelé optimiseur de
requêtes, lequel constitue l’élément essentiel de compétitivité
entre les SGBD actuels. De part son importance et son
indispensabilité, ce problème d’optimisation a intéressé une
panoplie de chercheurs depuis plus d’une trentaine d’années,
particulièrement depuis que Ibaraki et Kameda [11] ont
montré la NP-complétude de ce problème dans le cas de
jointures par boucles imbriquées.
Malheureusement, les solutions proposées jusqu’ici
présentent des insuffisances et ne s’appliquent généralement
pas à tous les types de requêtes. Afin de diminuer le temps
Ainsi, le problème crucial de la détermination de la
similarité entre les requêtes se transforme en un problème
d’isomorphisme de graphes.
Nous avons effectué des tests et les résultats obtenus ont
été comparés à ceux de l’optimiseur d’Oracle 11g.
II.
ETAT DE L’ART SUR L’OPTIMISATION DES REQUETES
L’optimisation des requêtes constitue l’un des aspects les
plus importants dans le domaine des bases de données, d’où
l’intérêt des chercheurs pour ce domaine, et ce depuis les
années 70. Plusieurs travaux de recherche ont proposé
diverses solutions s’inspirant, entre autre, de l’intelligence
artificielle, la théorie des graphes, etc. Il y a eu également
l’apparition de plusieurs surveys développés principalement
par les pionniers du domaine [17, 15, 12, 3].
A. Introduction au problème d’optimisation des requêtes
La nature déclarative des langages d’interrogation des
bases de données, – c.-à-d. que ces langages ne fournissent
aucune restriction à propos des chemins d’accès aux données
–, ainsi que l’évolution des structures d’optimisation,
conduisent à l’existence d’une multitude d’alternatives, pour
exécuter une requête aussi simple soit elle. Ces alternatives
sont toutes équivalentes en termes de résultat final, mais
peuvent avoir des coûts très différents. Ces coûts se
traduisent par les ressources qu’elles utilisent pour exécuter
la requête, d’où la nécessité d’optimiser les requêtes.
Cependant, l’augmentation de la complexité des requêtes et
du nombre de requêtes à traiter simultanément rend la tâche
d’optimisation très coûteuse en temps [13]. D’où le
problème d’optimisation des requêtes (Query Optimization
Problem -QOP-).
B. Déscription des différents modèles d’optimisation des
requêtes
Il existe essentiellement deux modes d’optimisation, le
premier à base de règles et le second à base de coûts. Le
premier bien qu’il soit facile à mettre en œuvre, reste
cependant très simpliste et donc peu fiable. Le second en
l’occurrence est beaucoup plus fiable, mais il est lent.
Suite à cela un troisième mode a été proposé ces
dernières années. Il se base sur l’exploitation des plans
d’exécution antérieurs afin de prédire les plans futurs (sur la
base d’une fonction de similarité). Quelques SGBD l’ont
déjà adopté mais sous des formes simples (à l’exemple
d’Oracle qui l’utilise dans un cadre très restreint qui est celui
de la similarité syntaxique).
1) Mode d’optimisation à base de règles
Dans cette approche (considérée comme la plus
ancienne), un ensemble de règles prédéfinies est appliqué par
l’optimiseur afin de générer un plan d’exécution, considéré
comme intéressant pour une requête donnée. Ces règles,
triées par ordre de priorité, indiquent les chemins d’accès et
les méthodes de jointure à utiliser selon les structures
d’optimisation disponibles.
Bien que ce type d’optimisation soit facile à mettre en
œuvre, il néglige cependant tous les paramètres physiques de
la base de données (taille des tables, facteurs de sélectivité
des prédicats de sélection et de jointure, etc.).
2) Mode d’optimisation à base de coût
Dans cette technique, un modèle mathématique est utilisé
afin d’estimer le coût de chaque plan. La solution optimale
est le plan ayant le coût minimum. Cette optimisation est
plus rigoureuse car elle prend en compte les données
physiques de la base.
Cette technique est celle utilisée actuellement par tous les
SGBD. Ce qui diffère, se sont les mécanismes utilisés pour
estimer le coût d’un plan d’exécution. Ces procédés sont
maintenus secrets par les concepteurs des SGBD, car se sont
eux qui déterminent la qualité de l’optimiseur de requêtes,
qui constitue l'élément de compétitivité entre les différents
SGBD.
Néanmoins l’optimisation à bases de coûts présente
quelques défauts, qui sont les suivants :
•
La nécessité d’avoir des statistiques fraîches sur la
base de données, et le coût de leur mise à jour.
•
Dans le cas où les plans candidats pour l’exécution
sont nombreux, l’optimiseur est contraint à
sélectionner un plan sous-optimal afin de respecter le
temps de réponse.
3) Mode d’optimisation basé sur la réutilisation des
plans d’exécution
Cette dernière technique est la plus récente. Elle se base
sur la réutilisation des plans d’exécution antérieurs, afin
d’anticiper la sélection des plans futurs en utilisant des
fonctions de similarité.
Cette technique n’est pas considérée comme une
technique d’optimisation de requêtes à part entière, mais elle
constitue une valeur ajoutée à l’optimiseur, car dans le cas
d’absence de similarité, on fait appel à l’optimiseur
classique. Cependant cette approche a pour avantage de
décharger l’optimiseur classique, et de lui permettre ainsi de
travailler dans son plus haut niveau, et par conséquent de
fournir des plans d’exécution de qualité. Ce qui se
répercutera positivement sur les plans des requêtes futures.
III.
TRAVAUX EN ANTERIEURS
Les méthodes basées sur la réutilisation des plans
d’exécution, ont pour but d’alléger la tâche de l’optimiseur
de requêtes, et d’accélérer ainsi le processus d’optimisation,
et par conséquent le temps de réponse. La diminution de la
charge sur l’optimiseur lui permettra également de travailler
dans son plus haut niveau, et d’offrir ainsi des plans de
qualité. Ces plans seront par la suite utilisés pour des
requêtes futures.
Il est à signaler que ce type d’optimisation constitue une
valeur ajoutée à l’optimiseur de requêtes en augmentant ses
performances, et non un modèle d’optimisation à part
entière.
Vu l’originalité de cette approche, plusieurs méthodes
basées sur la réutilisation des plans d’exécution ont été
proposées. Ces méthodes utilisent le même principe sous
des heuristiques différentes.
Elles s’inscrivent
essentiellement dans le domaine de l’optimisation multiple,
et celui de l’optimisation paramétrique. Dans lesquels les
requêtes sont modélisées sous forme d’arbres [10, 14] ou de
graphes [4, 2, 18]. La modélisation sous forme d’arbres fut
abandonnée, car elle s’est avérée trop restrictive (voir
exemple [2]). Les graphes quant à eux, se sont adaptés
naturellement à la structure même de la requête, ce qui fait
qu’ils soient largement utilisés pour représenter les requêtes,
et sont appelés Query Graph.
L’approche que nous avons proposée est basée
essentiellement sur deux méthodes récemment proposées
[16, 18].
La première [16] dans laquelle un outil appelé PLASTIC
(PLAn Selection Through Incremental Clustering) a été
proposé, dont le principe est d’établir des similarités entre les
requêtes en les représentant sous forme de vecteurs contenant
des attributs significatifs, tels que les tailles des tables, leur
nombre, etc. Ces vecteurs seront utilisés dans une fonction
de distance, grâce à laquelle les requêtes jugées similaires
(ayant le même plan d’exécution) seront regroupées dans des
clusters construits de façon incrémentale. Dès qu’une
nouvelle requête arrive elle sera assignée au cluster le plus
adéquat, et de ce fait s’exécutera sous le plan de ce cluster.
Bien que cette méthode soit riche, et couvre de façon
complète le processus d’optimisation des requêtes, réutilisant
les plans d’exécution, elle est cependant de complexité
exponentielle O(N!) – N étant le nombre de tables
impliquées dans la requête –, ce qui ne résout pas le
problème de la lenteur du processus d’optimisation. De plus,
elle ne prend pas en considération les coûts engendrés par les
jointures, ce qui peut entrainer des erreurs dans le calcul de
coût des requêtes impliquant ces opérations.
La seconde méthode [18] se base aussi sur la réutilisation
des plans d’exécution, mais s’inscrit dans un cadre
totalement différent, qui est celui de la détection de sous
requêtes similaires dans une requête complexe. Dans cette
approche, la requête est modélisée sous forme d’un graphe
étiqueté avec les informations essentielles requises pour
l’établissement de la similarité.
Une heuristique de
recherche des paires de sous requêtes similaires a été
proposée, elle a pour avantage d’être de complexité
polynomiale O(N4). Cependant cette méthode présente
quelques insuffisances qui sont: la recherche par paire de
sous requêtes similaires, la non garantie de trouver les sous
requêtes maximales, son applicabilité au cas restreint des
requêtes complexes possédant des sous requêtes similaires.
IV.
APPROCHE PROPOSEE
A. Domaine de requêtes considérées
Dans notre approche, nous traitons les requêtes simples
conjonctives comprenant les opérations de jointures et de
sélection.
Les requêtes considérées sont de la forme :
select * from R1, R2,… where jointure1, jointure2,…,
selection1, selection2,…
Les prédicats de jointure et de sélection considérés sont
de la forme R.a ø C ou R1.a1 ø R2.a2, où ø est dans {=, <, ≤,
>, ≥} et ø’ dans {=}; R, R1, R2 sont des tables de la base de
données, a, a1, a2 sont des colonnes sur ces tables
respectivement, et C une constante dans le domaine de R.a.
B. Modélisation des requêtes
Les requêtes sont modélisées sous forme de graphes
étiquetés non orientés.
1) Construction des graphes
Les graphes utilisés pour modéliser les requêtes sont
construits comme suit :
•
Chaque nœud du graphe correspond à une table de la
requête.
•
Chaque arête (Ni, Ni’), désigne l’existence d’une
relation de jointure entre les tables représentées par
les nœuds Ni, Ni’.
2) Etiquetage des graphes
Afin d’établir la comparaison entre les requêtes, nous
avons rajouté aux graphes précédents des informations. Ces
informations comprennent:
•
L’existence ou non d’index dans les opérations de
jointures et de sélection.
•
Les différents facteurs de sélectivité engendrés par
les opérations de jointure et de sélection. Ces
facteurs sont calculés à partir de formules simples
qui supposent que les données sont distribuées
suivant une loi uniforme [17].
Dans notre approche l’étiquetage se fait sur les nœuds et
les arêtes comme suit :
a) Etiquetage des nœuds
Sur les nœuds on retrouve les informations suivantes:
•
att_sel (Ni). Cet attribut est mis à 1 si la table
représentée par le nœud Ni possède au moins un
index sur l’un de ces attributs impliqués dans les
sélections.
•
fact_sel (Ni). Cet attribut représente le facteur de
sélectivité engendré par toutes les sélections
effectuées sur la table représentée par le nœud Ni.
b) Etiquetage des arêtes
Sur les arêtes on retrouve les informations suivantes :
•
att_join (Ni, Ni’). C’est un couple dans lequel
chaque attribut est mis à 1 si la table représentée par
son nœud possède un index sur l’attribut de jointure
correspondant à l’arête (Ni, Ni’).
•
fact_join (Ni, Ni’). Cet attribut représente le facteur
de sélectivité engendré par toutes les jointures entre
les tables représentées par les nœuds Ni, Ni’, ainsi
que toutes les sélections y ont été effectuées.
C. Etablissemnt de la similarité
La comparaison entre deux requêtes Q1, Q2 est établie
suivant le pseudo algorithme suivant :
Nouvelle
Requête
Construire son graphe
non étiqueté
Etablir de l’isomorphisme avec les
graphes non étiquetés d’anciennes
requêtes
Bool Comparaison (Q1,Q2)
Construction des graphes G1, G2 /* G1 est le graphe de
la requête optimisée et G2 est le graphe de la requête
à optimiser /*
Soit A= {C1, C2,…, Cn} // Les différentes
combinaisons assurant l’isomorphisme entre G1 et G2
non étiquetés.
Si A ≠ ø
Etablir de
l’isomorphisme avec
les graphes non
étiquetés d’anciennes
requêtes
Alors si ∃ Ck dans A tel que /* k dans {1,.., n}
Pour toute paire de nœuds Ni de G1 et Nj de G2 :
att_sel(Ni) ≤ att_sel(Ni’)
N
o
et|fact_sel(Ni) – fact_sel(Ni’)|/MAX((fact_sel(Ni),
fact_sel(Ni’)) < s
Faire appel à l’optimiseur
classique
O
Sauvegarder le nouveau
graphe dans un nouveau
cluster
et Pour toute paire d’arêtes similaires (Ni, Ni’) de
G1 et (Nj, Nj’) de G2 :
att_join (Ni, Ni’) ≤ att_join (Nj, Nj’)
Etiqueter du graphe
et |fact_join (Ni, Ni’) – fact_join (Nj, Nj’)|/
MAX ((fact_join (Ni, Ni’),fact_join (Nj, Nj’)) < s’
Alors similarité (Q1, Q2)=Vrai
Sinon similarité (Q1, Q2)=Faux
Etablir de
l’isomorphisme avec
les graphes non
étiquetés d’anciennes
requêtes
Finsi
Sinon similarité (Q1, Q2)=Faux
Finsi
Figure 1. Pseudo algorithme pour l’établissement de la similarité
Appliquer le même
plan d’exécution
que la requête
correspondante
s et s’ sont des seuils pouvant être déterminés
expérimentalement.
D. Architecture du système
Les requêtes déjà optimisées sont stockées dans des
clusters. Chaque cluster contient les requêtes dont les
graphes non étiquetés sont isomorphes (figure 2).
Lorsqu’une nouvelle requête arrive, on lui construit en
premier lieu son graphe non étiqueté qui sera comparé aux
graphes représentant les clusters. Cette première étape a
pour but de diminuer le nombre de comparaisons et d’arrêter
le processus de comparaison tôt dans le cas où aucune
requête similaire n’est stockée. Si aucune similarité n’est
trouvée, un graphe étiqueté de cette requête est établi et sera
sauvegardé dans un nouveau cluster qui sera représenté par
son graphe non étiqueté. Dans le cas contraire, un graphe
étiqueté de cette requête est construit et sera comparé aux
requêtes appartenant au cluster correspondant. S’il y a une
similarité, le plan de la requête similaire sera appliqué à la
nouvelle requête, sinon le graphe étiqueté de la nouvelle
requête sera stocké dans le cluster correspondant et servira à
enrichir l’ensemble des graphes utiles à la comparaison.
O
N
Faire appel à l’optimiseur
classique
Sauvegarder le nouveau
graphe dans le cluster
correspondant
Figure 2.
V.
Architecture du système proposé
TESTS ET RESULTATS
A. Outils utilisés
Afin d’effectuer les tests, nous avons utilisé les outils
suivants :
•
L’optimiseur d’Oracle 11g pour valider notre
approche.
•
La librairie VFLIB version 2 [6] pour la construction
et l’établissement de l’isomorphisme. Cette libraire
utilise
comme
algorithme
d’isomorphisme
l’algorithme VF. Cet algorithme est de complexité
temporelle allant de O(N²) à O(N!N) [5] suivant les
types des graphes, où N est le nombre de nœuds.
Cette complexité est celle de notre algorithme, car
toutes les autres fonctions de l’algorithme sont de
complexité polynomiale.
•
Visual C++ version 9 pour implémenter notre
algorithme.
•
Une machine ayant un processeur core 2 duo, avec 2
GB de RAM.
B. Tests effectués
Nous avons effectué des tests sur le benchmark APB1 [1]
qui contient au total 55 requêtes. Ces requêtes ont été
transformées en la forme considérée. Les informations
nécessaires sur le Benchmark APB1, ainsi que la façon dont
il a été exploité sont résumées dans le tableau suivant :
TABLE I.
CARACTERISTIQUES DES REQUETES DU BENCHMARK APB1
Nombre de
jointures
Nombre
requêtes
de
Nombre de requêtes pour
l’apprentissage
1
31
7
2
11
3
3
6
1
4
7
2
Figure 3. Temps d'optimisation moyen (secondes) d'Oracle et de notre
outil (seuil 0.3) suivant le nombre de jointures
Remarques.
•
Pour nos tests les seuils s et s’ ont été fixés à 0.3.
•
Vu la taille réduite de l’ensemble d’apprentissage,
nous avons choisi les requêtes qui le composent les
plus hétérogènes possibles, pour qu’il soit
suffisamment représentatif de l’ensemble de requêtes
considéré.
C. Résultats obtenus
Pour valider notre approche, deux paramètres ont été pris
en considération, à savoir :
•
Le temps d’optimisation.
•
Le taux de prédictions conformes à celles d’Oracle.
Les résultats relatifs au premier paramètre sont résumés
dans les graphes suivants :
Figure 4. Temps d’optimisation moyen en secondes d’Oracle et de notre
outil (seuil 0.3) pour toutes les requêtes du benchmark APB1
Les résultats obtenus se présentent comme suit :
•
Notre outil est en moyenne plus de 12 fois plus
rapide que l’optimiseur d’Oracle 11g.
•
Près de 70% de nos prédictions sont conformes à
celles d’Oracle. Les prédictions non conformes sont
toutes de type faux négatif c.-à-d. que notre outil
suppose que deux requêtes ne sont pas similaires
alors qu’Oracle leur sélectionne le même plan
d’exécution (ce résultat peut être amélioré en
augmentant les seuils mais cela risque de générer des
erreurs du type inverse).
VI.
CONCLUSION
Nous avons présenté une approche d’optimisation de
requêtes basées sur la réutilisation des plans d’exécution.
Cette façon de faire a pour but principal de décharger
l’optimiseur de requêtes et de lui permettre ainsi de travailler
dans son plus haut niveau, sans oublier le but principal de
cette approche qui est celui de réduire le temps
d’optimisation en réutilisant des plans déjà générés.
Dans notre approche, la requête est modélisée sous forme
d’un graphe souvent appelé Query Graph, sur lequel sont
greffées les informations nécessaires décrivant la requête.
Ces informations concernent les facteurs de sélectivité ainsi
que la disponibilité des index. Les requêtes considérées sont
des requêtes simples contenant les opérations de jointures et
de sélection.
L’utilisation des graphes à transformé le problème de
comparaison des requêtes en un problème d’isomorphisme
de graphes. Pour établir l’isomorphisme nous avons utilisé
l’algorithme VF considéré comme l’un des plus performants
[7].
Les tests effectués sur le Benchmark APB1, avec un seuil
de 0.3, ont donné des résultats satisfaisants, à savoir que
notre outil est en moyenne plus de 12 fois plus rapide que
l’optimiseur d’Oracle 11g, avec près de 70% de bonnes
prédictions.
Il reste cependant à introduire les opérations de
projections, ainsi que la prise en compte d’autres structures
d’optimisation que les index, comme les vues matérialisées.
REFERENCES
[1]
[2]
APB1 OLAP Council, “APB-1 olap benchmark, release II,”
http://www.olapcouncil.org/research/bmarkly.htm.
U.S. Chakravarthy and J. Minker, “Multiple Query Processing in
Deductive Databases using Query Graphs, ” VLDB Conference,
pages 384-391, 1986.
[3]
[4]
[5]
[6]
[7]
[8]
S. Chaudhuri, “An overview of query optimization in relational
systems,” In Proceedings of the Seventeenth ACM SIGACTSIGMOD-SIGART Symposium on Principles of Database Systems.
ACM Press, pages 34 –43, 1998.
F.C.F. Chen and M. H. Dunham, “Common subexpression processing
in multiple-query processing,” IEEE Transactions on Knowledge and
Data Engineering, Vol 10, No 3, pages 493–499, 1998.
L.P. Cordella, P. Foggia, C. Sansone, M. Vento, “Performance
evaluation of the VF Graph Matching Algoritmh, ” Proc. of the 10th
ICIAP, IEEE Computer Society Press, pages 1172–1177, 1999.
P. Foggia, “The vflib graph matching library, ” version 2.0. 2001.
http://amalfi.dis.unina.it/graph/db/vflib-2.0/doc/vflib.html.
P. Foggia, C. Sansone, M. Vento, “A performance comparison of five
algorithms for graph isomorphism, ” Proceedings of the 3rd IAPRTC15 Workshop on Graph based Representation (GbR2001), Italy,
2001.
G. Gardarin, “Bases de données,” Eyrolles Ed., pages 301–349, 2005.
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
A. Ghosh, J. Parikh, V. Sengar and J. Haritsa, “Plan Selection based
on Query Clustering,” Proc. of 28th Intl. Conf. on Very Large Data
Bases (VLDB), pages 179–190, Hong Kong, China, August 2002.
P.A.V. HALL, “Common suhexpression identification in general
algebraic systems,” Tech. Rep. UKSC 0060, IBM United Kingdom
Scientific Centre, Nov. 1974.
T. Ibaraki and T. Kameda, “On the optimal nesting order for
computing n-relational joins,” ACM-TODS, pages 482–502,
September 1984.
Y. Ioannidis, “Query Optimization,” ACM Computing Surveys,
symposium issue on the 50th Anniversary of ACM, Vol. 28, No. 1,
pages 121–123, March 1996.
Y. Ioannidis and Y. Kang. “Randomized algorithms for optimizing
large join queries,” In Proc. ACM-SIGMOD Conference on the
Management of Data, pages 312–321, Atlantic City, NJ, May 1990.
M. Jarke, “Common subexpression isolation in multiple query
optimization,” Querz Processing in Database Systems, pages 191–
205, 1984.
M. Jarke and J. Koch, “Query optimization in database systems,”
ACM Computer Surveys, Vol 16, pages111–152, 1984.
P. Sarda and J. Haritsa, “Green Query Optimization: Taming Query
Optimization Overheads through Plan Recycling,” Proc. of 30th Intl.
Conf. on Very Large Data Bases (VLDB), pages 1333–1336,
Toronto, Canada, September 2004.
P. Selinger, M. Astrahan, D. Chamberlin, R. Lorie, T. Price, “Access
path selection in relational database systems,” In: Proc. Of SIGMOD.
pages 23–34, Boston, Mass., USA, 1979.
Q. Zhu, Y. Tao, and C. Zuzarte, “Optimizing complex queries based
on similarities of subqueries,” Information Systems, Vol 8, No 3,
pages 350–373, 2005.