Partie 16: Directive EXPLAIN
Les articles de la série
- Partie 1 : Construire le REPL
- Partie 2 : Sérialisation des données
- Partie 3 : Database
- Partie 4 : Tables
- Partie 5 : Parser les commandes, création de la boîte à outils
- Partie 6 : Parser les commandes SQL
- Partie 7 : Tuples de données
- Partie 8 : Contraindre les données via un schéma
- Partie 9 : Découper le stockage des tables en pages
- Partie 10 : Clefs primaires
- Partie 11 : Expressions Logiques SQL
- Partie 12 : Scans et filtrage
- Partie 13 : UTF-8 et caractères échappés
- Partie 14 : Attributs nullifiables
- Partie 15 : Index secondaires
- Partie 16 : Directive EXPLAIN
Bonjour à toutes et tous 😃
Par l'introduction des index secondaires nous avons ouvert tout un champ des possibles sur de la recherche de données plus efficiente. Mais nous n'avons vraiment parcouru que la moitié du chemin: nous savons indexer, mais pas rechercher dans cet index.
Afin de permettre de comprendre quand le query engine décide ou non de décider de l'utilisation des index secondaires. Nous allons introduire un modificateur d'exécution que nous allons appeler EXPLAIN
. Ce sera notre mode de debug pour bâtir des systèmes plus intelligents et complexes.
On a encore bien du pain sur la planche, mais au bout de 16 articles et je ne sais combien de millier de lignes de codes expliquées, vous commencez à prendre l'habitude. 😅
Parser
Tout commence par bâtir un parser pour détecter notre modificateur d'exécution.
Nous décidons que si le premier token est EXPLAIN, alors la commande doit-être debugguée.
EXPLAIN SELECT ...
Nous devons ainsi reconnaître le token EXPLAIN
.
La structure reconnue est un peu étrange
;
Le usize
représentera le nombre de bytes consommée pour parser le "EXPLAIN" s'il existe.
On est désormais en capacité de détecter notre nouveau modificateur.
On réalise également un utilitaire qui reconnaît directement notre modificateur.
Propagation du EXPLAIN
Une fois le modificateur EXPLAIN détectée ou non, il faut le propager dans l'exécution.
Etant donné que le modificateur induit un comportement différent, nous allons avoir deux types de retours:
- des résultat de commandes
- le résultat du
EXPLAIN
.
{%note%()} EXPLAIN va retourner une liste de détails. D'où le Vec<String>
{%end%}
Pour permettre à toutes les commandes de bénéficier du EXPLAIN, la détection est réalisée avant le parse de la commande elle-même.
On modifie le trait Execute
en rajoutant un flag booléen qui permet de passer l'exécution en "dry run" de debug ou non.
Le flag est propagé, jusqu'à atteindre la base de données et sa méthode select.
Pour le moment, nous n'en feront rien, mais ce n'est qu'une question de temps. 😄
Conclusion
L'article est court mais va permettre de construire la suite plus simplement.
Dans la prochaine partie nous allons attaquer le concept fondamentale de la base de données qu'est le logical plan.
Merci de votre lecture ❤️
Vous pouvez trouver le code la partie ici et le diff là.
Ce travail est sous licence CC BY-NC-SA 4.0.