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

Bonjour à tous,

J'ai une question concernant PostGreSQL.
Mon entreprise envisage une migration de MySQL à PostGreSQL pour diverses raisons et nous nous posions une question à propos des requêtes multi-thread.

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

Est-ce que cette fonctionnalité peut-être comparée à des solutions multithreads des concurrents propriétaires (Oracle, MS SQL, DB2, etc) ?
Est-ce qu'il y aura d'autres travaux à ce sujet ?

Je vous remercie d'avance.

Bertrand

Bonjour,

En version 9.5, il n'y a pas encore de parallélisme au niveau d'une
requête SQL.

L'évolution 9.6 "Parallel Sequential Scan" est un début de solution qui
prend la même direction que les fonctionnalités équivalentes des autres
SGBD propriétaires.
Elle n'est cependant pas compatible avec le partitionnement (pour le
moment).

C'est prometteur, il faut juste attendre que cela prenne en maturité.

Cordialement

Olivier GENTRIC
DBA Etudes Oracle et PostgreSQL

Le 21 avril 2016 à 14:26, Bertrand ROBERT <b(dot)robert(at)kifaisa(dot)com> a écrit :

> Bonjour à tous,
>
> J'ai une question concernant PostGreSQL.
> Mon entreprise envisage une migration de MySQL à PostGreSQL pour diverses
> raisons et nous nous posions une question à propos des requêtes
> multi-thread.
>
> 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
>
> Est-ce que cette fonctionnalité peut-être comparée à des solutions
> multithreads des concurrents propriétaires (Oracle, MS SQL, DB2, etc) ?
> Est-ce qu'il y aura d'autres travaux à ce sujet ?
>
> Je vous remercie d'avance.
>
> Bertrand
>

--
*Olivier GENTRIC*

*Mob : 06.67.49.53.47*
*Mail : olivier(dot)gentric(at)gmail(dot)com <olivier(dot)gentric(at)gmail(dot)com>*

Mais je peux vraiment en conclure qu'il y aura des avancées à ce sujet dans les versions futurs ? En gros parallel sequential scan n'est qu'une première étape mais sûrement pas la dernière ?
Je te remercie d'avance.

Bertrand

De: "Olivier GENTRIC" <olivier(dot)gentric(at)gmail(dot)com>
À: "b robert" <b(dot)robert(at)kifaisa(dot)com>
Cc: "pgsql-fr-generale" <pgsql-fr-generale(at)postgresql(dot)org>
Envoyé: Jeudi 21 Avril 2016 17:09:52
Objet: Re: [pgsql-fr-generale] Requête multi-thread

Bonjour,

En version 9.5, il n'y a pas encore de parallélisme au niveau d'une requête SQL.

L'évolution 9.6 "Parallel Sequential Scan" est un début de solution qui prend la même direction que les fonctionnalités équivalentes des autres SGBD propriétaires.
Elle n'est cependant pas compatible avec le partitionnement (pour le moment).

C'est prometteur, il faut juste attendre que cela prenne en maturité.

Cordialement

Olivier GENTRIC
DBA Etudes Oracle et PostgreSQL

Le 21 avril 2016 à 14:26, Bertrand ROBERT < b(dot)robert(at)kifaisa(dot)com > a écrit :

Bonjour à tous,

J'ai une question concernant PostGreSQL.
Mon entreprise envisage une migration de MySQL à PostGreSQL pour diverses raisons et nous nous posions une question à propos des requêtes multi-thread.

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

Est-ce que cette fonctionnalité peut-être comparée à des solutions multithreads des concurrents propriétaires (Oracle, MS SQL, DB2, etc) ?
Est-ce qu'il y aura d'autres travaux à ce sujet ?

Je vous remercie d'avance.

Bertrand

--
Olivier GENTRIC

Mob : 06.67.49.53.47
Mail : olivier(dot)gentric(at)gmail(dot)com

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.

Cordialement

Olivier

Le 21 avril 2016 à 17:10, Bertrand ROBERT <b(dot)robert(at)kifaisa(dot)com> a écrit :

> Mais je peux vraiment en conclure qu'il y aura des avancées à ce sujet
> dans les versions futurs ? En gros parallel sequential scan n'est qu'une
> première étape mais sûrement pas la dernière ?
> Je te remercie d'avance.
>
> Bertrand
>
> ------------------------------
> *De: *"Olivier GENTRIC" <olivier(dot)gentric(at)gmail(dot)com>
> *À: *"b robert" <b(dot)robert(at)kifaisa(dot)com>
> *Cc: *"pgsql-fr-generale" <pgsql-fr-generale(at)postgresql(dot)org>
> *Envoyé: *Jeudi 21 Avril 2016 17:09:52
> *Objet: *Re: [pgsql-fr-generale] Requête multi-thread
>
>
> Bonjour,
>
> En version 9.5, il n'y a pas encore de parallélisme au niveau d'une
> requête SQL.
>
> L'évolution 9.6 "Parallel Sequential Scan" est un début de solution qui
> prend la même direction que les fonctionnalités équivalentes des autres
> SGBD propriétaires.
> Elle n'est cependant pas compatible avec le partitionnement (pour le
> moment).
>
> C'est prometteur, il faut juste attendre que cela prenne en maturité.
>
> Cordialement
>
> Olivier GENTRIC
> DBA Etudes Oracle et PostgreSQL
>
> Le 21 avril 2016 à 14:26, Bertrand ROBERT <b(dot)robert(at)kifaisa(dot)com> a écrit :
>
>> Bonjour à tous,
>>
>> J'ai une question concernant PostGreSQL.
>> Mon entreprise envisage une migration de MySQL à PostGreSQL pour diverses
>> raisons et nous nous posions une question à propos des requêtes
>> multi-thread.
>>
>> 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
>>
>> Est-ce que cette fonctionnalité peut-être comparée à des solutions
>> multithreads des concurrents propriétaires (Oracle, MS SQL, DB2, etc) ?
>> Est-ce qu'il y aura d'autres travaux à ce sujet ?
>>
>> Je vous remercie d'avance.
>>
>> Bertrand
>>
>
>
>
> --
> *Olivier GENTRIC*
>
> *Mob : 06.67.49.53.47*
> *Mail : olivier(dot)gentric(at)gmail(dot)com <olivier(dot)gentric(at)gmail(dot)com>*
>
>

--
*Olivier GENTRIC*

*Mob : 06.67.49.53.47*
*Mail : olivier(dot)gentric(at)gmail(dot)com <olivier(dot)gentric(at)gmail(dot)com>*

Le 21 avril 2016 à 17:17, Olivier GENTRIC <olivier(dot)gentric(at)gmail(dot)com> a
écrit :

> 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.

Cordialement
>
> Olivier
>
> Le 21 avril 2016 à 17:10, Bertrand ROBERT <b(dot)robert(at)kifaisa(dot)com> a écrit :
>
>> Mais je peux vraiment en conclure qu'il y aura des avancées à ce sujet
>> dans les versions futurs ? En gros parallel sequential scan n'est qu'une
>> première étape mais sûrement pas la dernière ?
>> Je te remercie d'avance.
>>
>> Bertrand
>>
>> ------------------------------
>> *De: *"Olivier GENTRIC" <olivier(dot)gentric(at)gmail(dot)com>
>> *À: *"b robert" <b(dot)robert(at)kifaisa(dot)com>
>> *Cc: *"pgsql-fr-generale" <pgsql-fr-generale(at)postgresql(dot)org>
>> *Envoyé: *Jeudi 21 Avril 2016 17:09:52
>> *Objet: *Re: [pgsql-fr-generale] Requête multi-thread
>>
>>
>> Bonjour,
>>
>> En version 9.5, il n'y a pas encore de parallélisme au niveau d'une
>> requête SQL.
>>
>> L'évolution 9.6 "Parallel Sequential Scan" est un début de solution qui
>> prend la même direction que les fonctionnalités équivalentes des autres
>> SGBD propriétaires.
>> Elle n'est cependant pas compatible avec le partitionnement (pour le
>> moment).
>>
>> C'est prometteur, il faut juste attendre que cela prenne en maturité.
>>
>> Cordialement
>>
>> Olivier GENTRIC
>> DBA Etudes Oracle et PostgreSQL
>>
>> Le 21 avril 2016 à 14:26, Bertrand ROBERT <b(dot)robert(at)kifaisa(dot)com> a écrit
>> :
>>
>>> Bonjour à tous,
>>>
>>> J'ai une question concernant PostGreSQL.
>>> Mon entreprise envisage une migration de MySQL à PostGreSQL pour
>>> diverses raisons et nous nous posions une question à propos des requêtes
>>> multi-thread.
>>>
>>> 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
>>>
>>> Est-ce que cette fonctionnalité peut-être comparée à des solutions
>>> multithreads des concurrents propriétaires (Oracle, MS SQL, DB2, etc) ?
>>> Est-ce qu'il y aura d'autres travaux à ce sujet ?
>>>
>>> Je vous remercie d'avance.
>>>
>>> Bertrand
>>>
>>
>>
>>
>> --
>> *Olivier GENTRIC*
>>
>> *Mob : 06.67.49.53.47*
>> *Mail : olivier(dot)gentric(at)gmail(dot)com <olivier(dot)gentric(at)gmail(dot)com>*
>>
>>
>
>
> --
> *Olivier GENTRIC*
>
> *Mob : 06.67.49.53.47*
> *Mail : olivier(dot)gentric(at)gmail(dot)com <olivier(dot)gentric(at)gmail(dot)com>*
>

--
Guillaume.
http://blog.guillaume.lelarge.info
http://www.dalibo.com

Hello à tous,

A noter que Citusdata a open sourcé sa solution de clustering postgres qui
permet de lancer des query en parallèle sur plusieurs shards si j'ai bien
compris.
https://www.citusdata.com/docs/citus/5.0/aboutcitus/what_is_citus.html

Donc pas vraiment multithread, mais multihost multiprocess, ce qui à notre
niveau est très intéressant.

Si quelqu'un l'a testé je suis preneur des retours d'ailleurs.

Le 21 avril 2016 à 08:29, Guillaume Lelarge <guillaume(at)lelarge(dot)info> a
écrit :

> Le 21 avril 2016 à 17:17, Olivier GENTRIC <olivier(dot)gentric(at)gmail(dot)com> a
> écrit :
>
>> 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.
>
> Cordialement
>>
>> Olivier
>>
>> Le 21 avril 2016 à 17:10, Bertrand ROBERT <b(dot)robert(at)kifaisa(dot)com> a écrit
>> :
>>
>>> Mais je peux vraiment en conclure qu'il y aura des avancées à ce sujet
>>> dans les versions futurs ? En gros parallel sequential scan n'est qu'une
>>> première étape mais sûrement pas la dernière ?
>>> Je te remercie d'avance.
>>>
>>> Bertrand
>>>
>>> ------------------------------
>>> *De: *"Olivier GENTRIC" <olivier(dot)gentric(at)gmail(dot)com>
>>> *À: *"b robert" <b(dot)robert(at)kifaisa(dot)com>
>>> *Cc: *"pgsql-fr-generale" <pgsql-fr-generale(at)postgresql(dot)org>
>>> *Envoyé: *Jeudi 21 Avril 2016 17:09:52
>>> *Objet: *Re: [pgsql-fr-generale] Requête multi-thread
>>>
>>>
>>> Bonjour,
>>>
>>> En version 9.5, il n'y a pas encore de parallélisme au niveau d'une
>>> requête SQL.
>>>
>>> L'évolution 9.6 "Parallel Sequential Scan" est un début de solution
>>> qui prend la même direction que les fonctionnalités équivalentes des autres
>>> SGBD propriétaires.
>>> Elle n'est cependant pas compatible avec le partitionnement (pour le
>>> moment).
>>>
>>> C'est prometteur, il faut juste attendre que cela prenne en maturité.
>>>
>>> Cordialement
>>>
>>> Olivier GENTRIC
>>> DBA Etudes Oracle et PostgreSQL
>>>
>>> Le 21 avril 2016 à 14:26, Bertrand ROBERT <b(dot)robert(at)kifaisa(dot)com> a
>>> écrit :
>>>
>>>> Bonjour à tous,
>>>>
>>>> J'ai une question concernant PostGreSQL.
>>>> Mon entreprise envisage une migration de MySQL à PostGreSQL pour
>>>> diverses raisons et nous nous posions une question à propos des requêtes
>>>> multi-thread.
>>>>
>>>> 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
>>>>
>>>> Est-ce que cette fonctionnalité peut-être comparée à des solutions
>>>> multithreads des concurrents propriétaires (Oracle, MS SQL, DB2, etc) ?
>>>> Est-ce qu'il y aura d'autres travaux à ce sujet ?
>>>>
>>>> Je vous remercie d'avance.
>>>>
>>>> Bertrand
>>>>
>>>
>>>
>>>
>>> --
>>> *Olivier GENTRIC*
>>>
>>> *Mob : 06.67.49.53.47 <06.67.49.53.47>*
>>> *Mail : olivier(dot)gentric(at)gmail(dot)com <olivier(dot)gentric(at)gmail(dot)com>*
>>>
>>>
>>
>>
>> --
>> *Olivier GENTRIC*
>>
>> *Mob : 06.67.49.53.47 <06.67.49.53.47>*
>> *Mail : olivier(dot)gentric(at)gmail(dot)com <olivier(dot)gentric(at)gmail(dot)com>*
>>
>
>
>
> --
> Guillaume.
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>

--
*Baptiste Manson*
Paris - San Francisco
169 11th Street San Francisco 94103
T. + 1 415 400 6077
http://www.inovia.fr
<https://www.facebook.com/pages/Inovia-Team/147815591928404>
<https://twitter.com/inoviateam>
<https://www.linkedin.com/company/1099225?trk=tyah&trkInfo=tarId%3A1414773408012%2Ctas%3Ainovia%2Cidx%3A2-3-6>

> 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

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

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

Bonsoir,

Le 21 avril 2016 à 20:14, Bertrand ROBERT <b(dot)robert(at)kifaisa(dot)com> a écrit :

> 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.
>
>
Je pense que PostgreSQL répondra déjà à tout ça. PostgreSQL est un projet
d'avenir, dans le sens où il est soutenu par de nombreuses entreprises
réparties un peu partout dans le monde. Les deux plus gros contributeurs de
code sont actuellement EntrepriseDB et 2ndQuadrant. Certaines sociétés
disparaissent (pas d'exemple récent en tête), d'autres arrivent (comme
Postgres Pro en Russie). Vous n'aurez aucun mal à trouver toute l'aide dont
vous avez besoin, soit avec la communauté soit avec les entreprises qui
proposent développement, support, formation.

Mais le point le plus intéressant dans PostgreSQL est sa communauté. Je
vous empresse notamment fortement à participer aux différents événements
sur PostgreSQL en France (le pgday à Lille, les différents meetups à Paris,
Nantes, Lyon, Toulouse et bientôt Lille) comme dans le monde (PGCon à
Ottawa, Canada, PGConf.EU à Tallin, Estonie, cette année, etc.) pour vous
rendre compte de la diversité et de la richesse de la communauté.

--
Guillaume.
http://blog.guillaume.lelarge.info
http://www.dalibo.com

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)