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 (pgsql-fr-generale(at)postgresql(dot)org)