Re: Re: [pgsql-fr-generale] Re: [pgsql-fr-generale] Requête multi-thread

On Thursday, April 21, 2016 02:26:53 PM Bertrand ROBERT wrote:
> Sauf erreur de ma part, aujourd'hui une grosse requête n'est pas
> parallélisée sur plusieurs coeurs. Par contre j'ai vu des travaux en
> cours à ce sujet en lisant cet article :
> http://rhaas.blogspot.lu/2015/11/parallel-sequential-scan-is-committed.
> html

Oui, la prochaine version de postgres apporte enfin du parallelisme de 
requettes. C'est un travail qui a commencé il y a longtems (les 
fonctionalités pré-requises sont apparues version par version) et qui ne 
s'arrêtera pas avec PG 9.6.

> Est-ce que cette fonctionnalité peut-être comparée à des solutions
> multithreads des concurrents propriétaires (Oracle, MS SQL, DB2, etc) ?

Dans le principe, oui. Dans les détails, probablement pas. Le parallelisme 
de requette est une fonctionalité complexe et assez bas niveau, il y aura 
toujours des différences d'une bdd à une autre (coté performance mais 
surtout coté cas parallélisables). Ça n'est notament pas une fonctionalité 
isolée (donc oubliez les comparatifs qui disent "parallelquery=yes/no"), 
et PG 9.6 ne gère pas tous les cas (cela reste néanmoins des améliorations 
très excitantes).

Cela dit, puisque vous voulez comparer à d'autres bdd et que vous venez de 
MySQL, il faut se rappeler que MySQL n'a (autant que je sache) aucun 
support pour le parallelisme de requettes. Donc si ça ne vous manque pas 
dans votre bdd actuelle, il est probable que ça ne vous manque pas dans 
votre bdd future.

En cherchant "mysql parallel query" on tombe surtout sur l'idée de lancer 
plusieur requettes en parallèle, quite à découper automatiquement une 
requette existante coté applicatif et à filer les morceaux à mysql 
(l'outil shard-query par exemple). Il existe des solutions PG qui 
s'approchent de ce genre de technique (souvent placé plus du coté bdd que 
application). Mais ça n'a rien à voir avec le fait d'utiliser plusieur CPU 
pour une requette.


On Thursday, April 21, 2016 08:14:46 PM Bertrand ROBERT wrote:
> Niveau performance c'est un peu compliqué de donner une liste d'attente
> : je dirais bien que les performances soient au moins aussi bonne que
> sur MySQL voir mieux. Je suis administrateur système pas développeurs
> donc je ne peux malheureusement pas donner d'exemple concret :-/

J'ai envie de dire qu'en tant qu'administrateur, vous avez une meilleure 
visibilité des problèmes de performance de la bdd que ne peuvent l'avoir 
les développeurs de l'application. C'est eux qui ont écrit les requettes, 
mais c'est vous qui avez les outils pour voir quelles requettes sont 
executées le plus souvent, comment elles se comportent avec les données de 
production, etc.

Si vous vous inquiétez des différences de performance qu'apportera une 
migration, vous feriez bien de commencer par bien comprendre le profil de 
performance de votre solution actuelle.

-- 
Vincent de Phily


--
Envoi via la liste pgsql-fr-generale ([email protected])