Un PostgreSQL, trois questions : KealSql coûte-t-il quelque chose sur le chemin de la base, et que coûte Keal dans le serveur face à ses voisins, sur de l'arithmétique et sur du texte. Chaque nombre est le meilleur de trois exécutions, sur la machine nommée ; la procédure est bench/run.sh, et la lecture dans bench/README.md.
Machine : aarch64, 6 cores, Linux, PostgreSQL 18.6 (Ubuntu 18.6-0ubuntu0.26.04.1), keal 1.3.0
La même requête, 20 000 fois sur une connexion : psql exécutant des EXECUTE depuis un script, le client KealSql — un programme Keal sur libpq — et un programme C sur libpq, préparé une fois ou envoyant le texte à chaque fois. Les trois chemins préparés sont dans le bruit d'une exécution à l'autre (dix à vingt pour cent sur une machine virtuelle) : le temps est l'aller-retour et le serveur, et le client n'ajoute rien de mesurable. Envoyer le SQL en texte à chaque fois coûte un quart de plus — c'est ce que préparer achète, et ce que le compilateur fait pour chaque requête.
steps(n), le compte de Collatz, sur 300 000 lignes : la même boucle en stored func Keal — compilée via C en fonction LANGUAGE C — en PL/pgSQL, et écrite à la main en C. Keal est environ vingt fois plus rapide que PL/pgSQL et environ deux fois et demie plus lent que le C : la différence est l'arithmétique vérifiée de Keal et sa boucle, pas le pont, puisqu'un entier traverse comme un entier.
vowels(s), une boucle sur les quarante caractères de chacune de 300 000 lignes : Keal, PL/pgSQL, la fonction SQL translate(), et C. Keal est quatre fois plus rapide que PL/pgSQL et vingt fois plus lent que C : itérer une chaîne en Keal rend une petite chaîne par caractère, un coût du langage mesuré ailleurs aussi — une boucle sur des caractères est là où Keal est le plus lent. Et translate() en une expression SQL bat la boucle trois contre un : quand une fonction intégrée fait le travail, prenez-la ; KealSql les expose.
Les mêmes 20 000 appels sur trois serveurs, chacun depuis sa propre API C avec l'instruction préparée une fois — le compilateur hors jeu, les serveurs face à face. PostgreSQL 18 et MariaDB 11.8 répondent sur un socket et coûtent à peu près pareil ; SQLite tourne dans le processus appelant, donc sans aucun aller-retour, et il est six fois plus rapide — c'est ce qu'être embarqué achète, et ce que ça coûte est tout ce qu'un serveur fait pour plusieurs programmes à la fois.
La même boucle de Collatz sur 300 000 lignes dans le langage procédural de chaque serveur : Keal et PL/pgSQL sur PostgreSQL, une fonction SQL/PSM sur MariaDB, et sur SQLite une fonction C que le programme enregistre, SQLite n'ayant pas de fonctions stockées. L'interpréteur de MariaDB est sept fois plus lent que PL/pgSQL ; Keal sur PostgreSQL est cent quarante fois plus rapide que la fonction MariaDB et à moins de trois fois du C de SQLite. Les trois serveurs sont vérifiés d'accord sur le résultat avant d'être chronométrés.
La comparaison avec d'autres serveurs mesure ces serveurs, pas ce compilateur : KealSql compile vers PostgreSQL et ne tourne sur rien d'autre. Elle est ici parce que la question se pose, et parce que la réponse dit où se tient PostgreSQL.