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

Bonsoir,

Merci à tous pour vos réponses.
L'absence de ces fonctionnalités n'est pas en frein en tant que tel ; c'était plus par curiosité (savoir vers quoi se dirige PostGreSQL).

Par rapport à MySQL nos attentes sont relativement simples :
- meilleure gestion des locks
- meilleure performances
- moins de bugs
- solutions de sauvegarde évoluée
- un master / slave fiable / consistant

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 :-/

Je pense que PostGreSQL répondra déjà à nos besoins aujourd'hui et vos réponses sont intéressantes quant à l'avenir du projet.

Bonne soirée

Bertrand

De: "Cédric Villemain" <cedric(at)2ndquadrant(dot)com>
À: "b robert" <b(dot)robert(at)kifaisa(dot)com>
Cc: "Guillaume Lelarge" <guillaume(at)lelarge(dot)info>, "Olivier GENTRIC" <olivier(dot)gentric(at)gmail(dot)com>, "pgsql-fr-generale" <pgsql-fr-generale(at)postgresql(dot)org>
Envoyé: Jeudi 21 Avril 2016 18:19:41
Objet: Re: [pgsql-fr-generale] Re: [pgsql-fr-generale] Re: [pgsql-fr-generale] Requête multi-thread

> A mon avis oui, c'est un besoin récurrent au regard des volumétries
> de données croissantes.
> Il y a aussi d'autres pistes relatives au "sharding" avec un
> partitionnement réparti sur plusieurs moteurs PostgreSQL et donc un
> autre espoir de parallélisme à ce niveau.
>
>
> Le parallel seqscan n'est qu'une première étape. D'autres étapes sont
> déjà passées, notamment les jointures et les agrégats
> (http://rhaas.blogspot.fr/2016/03/parallel-query-is-getting-better-and.html)
> Évidemment, il reste du boulot, et il y a de fortes chances que cela
> continue. Néanmoins, il faut être réaliste : si les clients
> d'EntrepriseDB (qui est la société qui a principalement travaillé sur
> ces fonctionnalités) sponsorisent des fonctionnalités autres, EDB n'aura
> aucune motivation pour travailler sur le parallélisme. Je pense qu'il
> n'y a aucune chance que cela arrive, mais c'est une possibilité. Pour le
> dire, il n'y a aucune garantie, il n'y a que des fortes présomptions que
> la version suivante contiendra des nouveautés sur le parallélisme.

2ndQudrant travaille également activement sur le parallélisme, via
postgres-XL pour préparer le futur de PostgreSQL et directement dans
PostgreSQL, par exemple pour la dernière commit-fest :

* parallel aggregate https://commitfest.postgresql.org/9/551/
* Combine Aggs https://commitfest.postgresql.org/9/552/ (premier patch
en 2014 ....)

Comme le dit Guillaume, les demandes des utilisateurs (et des clients)
aident effectivement à développer certaines fonctionnalités, mais cela
ne s’arrête fort heureusement pas là, et une grande partie de nos
développements se fait aussi sur le budget de recherche de 2ndQuadrant
(aidée par des fonds publics) afin de permettre des évolutions que les
clients du secteurs privés ne sont pas toujours capables de sponsoriser
alors que nous les estimons nécessaires (par exemple: TABLESAMPLE,
pg_logical, replication slot, failover slot, les patchs sus-cités, etc.)

Il existe des solutions de parallélisation exploitables depuis de
nombreuses années avec PostgreSQL mais l'utilisation est plus complexe
et cela ne se pratique que pour gérer certains cas spécifiques car le
coût de mise en oeuvre est important.

Bertrand, quels sont vos attentes en terme de performance, de volume, de
qualité des données, ... ?
Ne voyez pas forcément un frein dans l'absence de fonctionnalités:
l'état actuel de PostgreSQL suffit à de très nombreux utilisateurs, peut
être que la parallélisation sera un "plus" pertinent mais pas
obligatoire pour l'adoption de PostgreSQL.

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services