Frais généraux des langages procéduraux PostgreSQL (plpython / plsql / pllua…)

J'essaie de trouver des informations sur les fonctions définies par l'utilisateur de PostgreSQL dans les performances des langages procéduraux pour les tâches en temps réel.

1. Comment se comparent-ils aux fonctions intégrées?
2. Y a-t-il une différence (dans les frais généraux) avec la façon dont Postgres appelle / gère les fonctions plpython vs plpgsql vs pllua (je m'intéresse au côté intégration / contexte / transfert de données Postgres, pas à la VM elle-même)?
3. Le contexte est-il un gros frais généraux? Puis-je l'utiliser pour le mappage de données en temps réel (disons 1000 requêtes / s))
4. Y a-t-il un avantage à écrire des fonctions définies par l'utilisateur dans plpgsql puis dans d'autres pg / langues? Sur la documentation, ils énumèrent les avantages, mais je pense qu'ils s'appliquent à tous les langages procéduraux postgresql.

Constatations connexes:

• Une vitesse des langages PL pour une utilisation atypique
• Performances du langage de fonction PostgreSQL: C vs PL / PGSQL

1. Les UDF dans les langages interprétés sont à peu près toujours plus lents que les UDF écrits en C ou dans les fonctions intégrées, toutes les autres choses étant les mêmes.

2. Chaque liaison de langage a un code différent pour connecter PostgreSQL au langage, avec différents degrés d'optimisation, différentes façons de transmettre certains types de données, etc. Il existe donc certainement une variation. Cela ne devrait pas être énorme à moins que vous ne passiez un type de données qui obtient une gestion très différente par une langue que par une autre, par exemple, on passe un hstorecomme une chaîne et un autre le convertit en un dict.

3. On ne sait pas ce qu'est "le contexte". Pouvez-vous l'utiliser pour le "mappage de données en temps réel" ... eh bien, cela dépend de ce que fait la fonction et si elle est assez rapide sur le serveur sur lequel elle s'exécute, pour les clients vers lesquels elle se dirige et pour vos besoins. Quelle est la longueur d'une ficelle? Référence.

4. PL / PgSQL est plus simple à écrire et offre un accès plus rapide à SQL. C'est généralement mieux lorsque vous devez encapsuler un peu de logique autour de beaucoup de SQL. C'est très lent pour les opérations mathématiques et les algorithmes complexes, donc le code purement computationnel en PL / PgSQL devrait être évité autant que possible en faveur de C, ou d'un langage procédural plus rapide.

Les accélérations lors de la réimplémentation du code PL / PgSQL en C peuvent varier de négligeables à plus de 1000 fois. Tout dépend de ce que fait réellement le code.

(Ce type de questions multiples n'est pas bien adapté à Stack Exchange car il est plus difficile d'avoir une réponse définitive)

c'est assez difficile à dire. cela dépend vraiment de ce que vous faites. par exemple: PL / pgSQL est merveilleux si vous avez de grandes instructions SQL dedans - ça devient vraiment fou si vous avez toutes sortes de branchements, de gestion de sous-chaînes et tout ça.

il faut vraiment tester au cas par cas.

Le contexte est-il un gros frais généraux? Puis-je l'utiliser pour le mappage de données en temps réel (disons 1000 requêtes / s))

Les performances dépendent du matériel et de la complexité de vos fonctions. J'ai créé une appliance qui fonctionnait sur un petit serveur 12 cœurs et une carte FusionIO (coût total 10000 euros) et j'ai effectué environ 2500 transactions par seconde avec 20 utilisateurs simultanés. Chaque transaction appelle 29 procédures stockées pour traiter les données et renvoyer des informations utiles au client. Certaines fonctions exécutent une seule requête, d'autres quelques requêtes. Au total, il exécute environ 200 000 instructions INSERT, SELECT et UPDATE par seconde.

Tout cela est écrit en PL / SQL, PL / pgSQL et PL / PerlU. Et je suis sûr que le système peut fonctionner encore plus rapidement lorsque (certaines) fonctions sont réécrites en C.

Dans cet appareil, la plupart des performances proviennent de la carte SSD. Sur un seul disque rotatif, nous n'obtiendrions jamais cette performance. Les disques SSD bon marché échouent également, cela fonctionne pendant une heure (en raison de la mise en cache de la carte de raid), puis la partie est terminée. La carte FusionIO est chère, mais un très bon investissement lorsque vous êtes lié aux E / S.