Dans les versions récentes de PostgreSQL (à compter de décembre 2013), pouvons-nous partager une requête entre deux cœurs ou plus pour améliorer les performances? Ou devrions-nous obtenir des noyaux plus rapides?
57
Dans les versions récentes de PostgreSQL (à compter de décembre 2013), pouvons-nous partager une requête entre deux cœurs ou plus pour améliorer les performances? Ou devrions-nous obtenir des noyaux plus rapides?
Non, pour les versions de PostgreSQL antérieures à la v9.6. Veuillez consulter la FAQ de PostgreSQL : Comment PostgreSQL utilise-t-il les ressources du processeur?
Le serveur PostgreSQL est basé sur un processus (pas de thread). Chaque session de base de données se connecte à un processus unique du système d'exploitation PostgreSQL . Plusieurs sessions sont automatiquement réparties sur tous les processeurs disponibles par le système d'exploitation. Le système d'exploitation utilise également des processeurs pour gérer les E / S du disque et exécuter d'autres tâches non liées à la base de données. Les applications client peuvent utiliser des threads, qui se connectent chacun à un processus de base de données distinct.
Depuis la version 9.6, des parties de certaines requêtes peuvent être exécutées en parallèle, dans des processus de système d'exploitation distincts, permettant ainsi l'utilisation de plusieurs cœurs de processeur. Les requêtes parallèles sont activées par défaut dans la version 10 (max_parallel_workers_per_gather), un parallélisme supplémentaire étant prévu dans les prochaines versions.
PostgreSQL 9.6+ , commencerait à voir Parallel-Query enfin arriver à PostgreSQL.
Par exemple, des concepts tels que Numérisation parallèle / Jointure parallèle / Agrégats parallèles sont déjà intégrés, et d’autres à venir prochainement.
Ce qui est vraiment intéressant, c’est que des rapports confirment near-linear speed-updans certains cas, ce qui est assez impressionnant!
Non, mais il existe une solution de contournement. :)
J'ai trouvé la fonction plselx (sélection parallèle) plpgsql, qui divise votre requête en clé primaire, puis se connecte à la base de données via l'extension dblink et attend toutes les sous-requêtes.
https://gist.github.com/mjgleaso/8031067
L'auteur a également écrit un article sur cette fonction: http://geeohspatial.blogspot.com/2013/12/a-simple-function-for-parallel-queries_18.html
Non. Chaque connexion génère un processus distinct sur le serveur.
Vous pouvez "émuler" un peu de parallélisme en utilisant un langage procédural tel que pljava. Créez une procédure java (fonction) qui lance plusieurs threads et créez le résultat en sortie à l'aide de plusieurs travailleurs. Le backend est synchronisé afin que chaque utilisateur puisse mettre à jour la sortie de manière asynchrone.
Java supporte bien la coordination / coopération des threads.
À titre d’exemple, cela serait utile pour les opérations nécessitant une utilisation intensive du processeur ou les opérations de longueur du réseau.