Discussion :

[Victor Vincent]

PostgreSQL 9.6 est disponible en version bêta, cette version vient avec le support du parallélisme
et de la recherche plein texte de phrases

Le PostgreSQL Global Development Group vient d'annoncer la sortie de la première version bêta de PostgreSQL 9.6. Cette version donne un aperçu des différentes fonctionnalités qui seront présentes dans la version finale, même si certains détails peuvent encore changer, souligne l’équipe derrière le système de gestion de bases de données. La version bêta de PostgreSQL 9.6 vient avec plusieurs changements importants ainsi que des améliorations. Parmi les plus remarquables, le groupe met en avant :

• le parallélisme : qui permet de faire en sorte que les parcours séquentiels, les jointures et les agrégats puissent désormais être exécutés en parallèle ;
• la cohérence des lectures entre plusieurs nœuds Hot Standby synchrones ;
• la recherche plein texte de phrases ;
• la possibilité avec un connecteur postgres_fdw d’exécuter des requêtes de tris, de jointures ainsi que des requêtes de type UPDATE et DELETE sur des serveurs distants ;
• la réduction de l'impact des autovacuum sur les grandes tables en évitant de « refreezer » les données anciennes.

D’après le PostgreSQL Global Development Group, ces nouveautés apportées par la version 9.6, dont le parallélisme, devraient apporter un gain de performance important pour certaines requêtes. Comme pour toutes les versions majeures, les améliorations de PostgreSQL impliquent des modifications sur de très grandes parties du code, souligne le PostgreSQL Global Development Group. Le groupe prévoit la sortie de la version finale de PostgreSQL 9.6.0 très prochainement si les retours des utilisateurs de la communauté permettent de corriger rapidement d’éventuels bogues et faire si nécessaire certaines améliorations mineures.

La version 9.6 bêta 1 de PostgreSQL modifie également l'API des backups binaires. Les administrateurs de bases de données ont maintenant la possibilité avec cette version d’utiliser des outils de sauvegarde tels que pgBackRest, Barman, WAL-E ou tout autre outil interne ou packagé, souligne le PostgreSQL Global Development Group. Avant la sortie de la version finale, l’équipe prévoit d’effectuer des modifications mineures au niveau du comportement, des fonctionnalités et des API de PostgreSQL et fait appel à la communauté pour tester cette version afin, dit-elle, de finaliser les nouveautés. L’équipe derrière PostgreSQL déclare que d’autres versions bêta sortiront au fur et à mesure, en fonction des nécessités, suivies de versions candidates. La version finale 9.6.0 quant à elle est prévue pour fin 2016.

Télécharger PostgreSQL 9.6

Source : postgresql.org

Et vous ?

Que pensez-vous de cette nouvelle version bêta de PostgreSQL ?

Voir aussi

le forum PostgreSQL

[SQLpro]

Deux vrais bonnes nouvelles :

• le parallélisme des requêtes longtemps attendu... qui faisait que pour les gros volumes PostgreSQL était un veau ! À tester donc...
• Un meilleur algorithme pour l'utilisation de AUTOVACUUM sui générait des deadlocks en pagaille.

Il resterait à faire nettement mieux sur le processus de VACUUM en général car il est lourd, long et bloquant ce qui ne permet toujours, en pratique, pas d'utiliser PG pour des applications critiques qui doivent fonctionner 24/24 et 7/7.

A +

[Gugelhupf]

Je ne connais pas pas d'appli critique qui tourne 24h/24 et 7j/7 (ps: je dis cela en ayant travaillé dans une banque, tu as au moins une heure de pause le dimanche).
Le vacuum de PostgreSQL est une stratégie comme une autre. Si on prend l'exemple du Ghost cleanup task de SQL Server (je fais référence à ce dernier car je sais que tu aimes beaucoup ce SGBDR), pourrais-tu prouver que ce modèle est meilleur sur tous les points ? Qu'il n'y a jamais de freeze etc ?

[SQLpro]

Je ne connais pas pas d'appli critique qui tourne 24h/24 et 7j/7 (ps: je dis cela en ayant travaillé dans une banque, tu as au moins une heure de pause le dimanche).

Je possède beaucoup de client qui ont des bases 24/24 7/7 sans aucune heure creuse sous SQL Server et avec obligation de fonctionner à minima en 99.999% du temps voir plus. Petits exemples :
BSPP (sapeurs pompier de Paris, système d"alerte et de suivi des interventions en live...) à paris
SPC GD (Servcie de prévision des crues du grand delta du Rhone) département du Gard
ALSTOM : maintenance Worldwide des tramways (il y en a en France, à Dubai, à Rio...) ils ne s'arrêtent pas le dimanche !!!
EDF : système d'analyse par remontées des "logs" des pannes informatiques des systèmes de toutes les centrales énergétiques de France (CEP via StreamInsight)
GEODIS : système worldwide de gestion du colisage par route, air, mer, fer au niveau mondial (base de 7 To)
BOLLORÉ TRANSPORT & LOGISTICS : système worldwide de gestion du colisage par route, air, mer, fer au niveau mondial (base de 500 Go)
IRSN (institut de recherche et de sureté nucléaire) base mondiale de collecte des données de rayonnement servant en cas d'alerte sur le sol français
ITER (pôle de fusion nucléaire à Cadarache) plusieurs dizaines de BD de grand volume travaillant 24/24 et 7/7
IDEX : contrôle centralisés de la gestion des services généraux communs des immeubles (chauffage, eau froide, eau chaude, ascenseur, éclairage, distribution eau et gaz, etc...) notamment pour des immeubles "industriels" types hôpitaux !
PROTECTION24 : centralisation des alarmes et télésurveillance d'habitation.
RADIO FRANCE : gestion de la grille des programme et du conducteur (direct) pour plus de 100 stations.
SGS : contrôle worldwide de process industriels d'usine fonctionnant 24/24
...

Dans une moindre mesure :
CDiscount, fnac.com, ventres privées...

Le vacuum de PostgreSQL est une stratégie comme une autre. Si on prend l'exemple du Ghost cleanup task de SQL Server (je fais référence à ce dernier car je sais que tu aimes beaucoup ce SGBDR), pourrais-tu prouver que ce modèle est meilleur sur tous les points ? Qu'il n'y a jamais de freeze etc ?

Le VACUUM génère des deadlock et des attentes monstrueuses alors que le ghost cleanup de SQL Server n'a jamais posé de problème en particulier aucun deadlock (ça n'est pas possible vu sa stratégie) mais bien quelques attentes peu importantes et rarement détectables en tout cas aucun freeze à ma connaissance !

A +

[stb007]

L’exécution parallèle existe sur MySQL ? Juste une question car je sais que sous Oracle j'ai l'habitude de faire du parallèle sur les tables partitionnées (parcours de plusieurs partitions en même temps) mais je ne savais pas que ça pouvait aussi fonctionner sur des tri et des jointures, a votre avis pour un nouveau projet vaut-il mieux partir sur du MySQL (ou ses fork genre MariaDB) ou sur du postgres ? J'ai toujours eu l'impression que postgresql était en avance sur mysql mais sans avoir réellement comparé feature par feature.

[SQLpro]

L’exécution parallèle existe sur MySQL ?

Non

Juste une question car je sais que sous Oracle j'ai l'habitude de faire du parallèle sur les tables partitionnées (parcours de plusieurs partitions en même temps) mais je ne savais pas que ça pouvait aussi fonctionner sur des tri et des jointures,

Sous Oracle c'est une option à activer qui est payante et très chère !

Sous SQL Server c'est natif depuis la version 7 quelque soit l'édition (même gratuite)

a votre avis pour un nouveau projet vaut-il mieux partir sur du MySQL (ou ses fork genre MariaDB) ou sur du postgres ? J'ai toujours eu l'impression que postgresql était en avance sur mysql mais sans avoir réellement comparé feature par feature.

Des différences énormes... Outre la performance, MySQmerde ne dispose toujours pas des CTE, fonctions de fenêtrage, requêtes récursives, schéma SQL ni d'une sauvegarde à chaud !!!
En plus c'est hyper bugué et de nombreuses requêtes donnent des résultats faux car mySQmerde confond les NULL et les zéros et chaines vides et ne part pas en exception dans de nombreux cas d'erreur !

A lire sur MySQLmerde :
http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

A +

[Gugelhupf]

Avoir un processus qui se lance toutes les 5 ou 10 secondes en fond de tache pour nettoyer les tuples qui ont été delete/update n'est pas toujours perceptible à l'échelle humaine, aussi pratique soit-il son comportement n'est pas prévisible dans le cas où des deletes/updates sont effectués de manières intensifs, cela peut causer des lags. Le vacuum est prévisible dans le sens où on sait à l'avance que le nettoyage possède une durée, l'inconvénient c'est de savoir quand lancer ce processus de nettoyage.
Si on souhaite mettre en avant l'aspect critique, il faut mettre en avant les notions liées à la réplication (master-master par exemple). Est-ce que les systèmes cités possèdent plusieurs noeuds pouvant prendre la relève en temps réel (et sans intervention humaine) dans le cas d'une défaillance d'un noeud ?

[SQLpro]

Oui pour Oracle c'est DataGuard et/ou éventuellement RAC
Pour SQL Server c'est le mirroring (un seul nœud) ou AlwaysOn (jusqu'à 8 nœuds dont 2 synchrones)
Par exemple, en mode synchrone, le basculement est automatique et sans délai pour SQL Server.

A +

[Olivier Famien]

La version finale de PostgreSQL 9.6 est annoncée pour le 29 septembre prochain
avec plusieurs améliorations, mais les requêtes parallèles sont désactivées par défaut

Depuis le 1er septembre, PostgreSQL 9.6 a passé la phase bêta pour revêtir sa première release candidate. Dans cette nouvelle version, plusieurs améliorations et éléments nouveaux ont été apportés. Nous avons entre autres éléments :

• l’ajout des fonctions SQL pour inspecter les méthodes d’accès aux index ;
• la correction de divers bogues qui ont commencé à pointer le nez dans les index ;
• l’ajout de tests de régression pour les bugs d’insertion de TOAST ;
• la correction du traitement des erreurs des requêtes parallèles dans les paramètres de langues qui ne sont pas en anglais ;
• L’intégration de plusieurs mises à jour dans la documentation ;
• Les requêtes parallèles ont été désactivées par défaut dans postgresql.conf. Elles peuvent être activées avec la commande suivante max_parallel_workers_per_gather.

Selon les dires de PostgreSQL Global Development Group, la version 9.6 RC 1 devrait être identique à la version finale à sa sortie. Il va sans dire que les développeurs peuvent déjà savoir quelles sont les fonctionnalités définitives qui abriteront cette nouvelle version majeure.

Comme recommandé par le groupe, les développeurs ont déjà commencé à tester cette version RC1 sous toutes ses coutures. Après plus de trois d’essais, il est donc légitime que les regards se tournent maintenant vers la version finale.

Tom Lane, membre du comité du noyau de PostgreSQL, vient de donner quelques détails sur la date de sortie de cette version 9.6 dans un message adressé à la communauté. Dans le message, il dit ceci : « Toutes mes excuses pour l’avis tardif sur ce sujet, mais l’équipe de presse a conclu que PostgreSQL 9.6 est à peu près aussi prêt qu’il doit l’être. Nous prévoyons d’aller de l’avant avec la sortie de la 9.6.0 la semaine prochaine --- c’est-à-dire, s’apprêter le lundi 26 pour une annonce publique le jeudi 29 ».

PostgreSQL sortira donc officiellement le jeudi 29 septembre prochain, selon le message émis par Lane.

Source : PostgreSQL

Et vous ?

Avez-vous testé la version 9.6 RC1 ? Comment l'avez-vous trouvée ?

Quelles sont améliorations que vous attendez pour cette nouvelle version majeure ?

Voir aussi

PostgreSQL

[stef-13013]

Ce qui est intéressant c'est de voir qu'aujourd'hui les "grands groupes" restent sur des bases comme SqlServer ou Oracle
ultra propriétaires et payantes (et pas qu'un peu) alors qu'ils ont à leur disposition gratuitement un des meilleurs moteurs au monde !?

Va comprendre...

De plus, mais c'est un avis perso., Oracle reste le top et seul PG arrive à son niveau (attention avis perso. je le repète)

Compliqués ces humains

[SQLpro]

Ce qui est intéressant c'est de voir qu'aujourd'hui les "grands groupes" restent sur des bases comme SqlServer ou Oracle
ultra propriétaires et payantes (et pas qu'un peu) alors qu'ils ont à leur disposition gratuitement un des meilleurs moteurs au monde !?

Il y a le poids du passé et l'inertie des données qui jouent dans bon nombre d'entreprises... Reste que PG, même si c'est sans conteste le meilleur SGBD libre (et un vrai libre, contrairement à MySQL), n'est pas du tout à la hauteur dès que les bases sont conséquentes, complexes ou fortement sollicités. En sus un outil comme SQL Server c'est une suite de 4 outils. Outre le moteur relationnel il y a le moteur décisionnel (stockage, datamining), le serveur de rapport et l'ETL... Rien de cela n'existe avec PG... Enfin, beaucoup de fonctionnalités sont en retard ou manquantes... Le traitement du XML est faiblard, le partitionnement nullissime, les vues matérialisées embryonnaires, les tables temporelles inexistantes, tout comme le DATALINK, le chiffrement TDE ou la réplication des données...

Va comprendre...

De plus, mais c'est un avis perso., Oracle reste le top et seul PG arrive à son niveau (attention avis perso. je le repète)

Oracle est en fort déclin et n'est plus du tout au top sur aucun domaine. Il est dépassé depuis longtemps sur le plan de la fiabilité, de la sécurité, et plus récemment des performances et depuis toujours des prix !
A lire : http://blog.developpez.com/sqlpro/p1...-declin-oracle
Beaucoup d'entreprises aux USA ont migré d'Oracle vers SQL Server en grande majorité. Comme toujours, la France est en retard, mais certaines grandes entreprises ont déjà migré et d'autres sont en train de la faire. Dernier exemple en date l'Oréal.

Compliqués ces humains

Il suffit de faire des benchmarks et de comparer...

A +

[Kearz]

PG s'améliore, c'est bien. Après, c'est logique que tout le monde ne soit pas sous PG face à Oracle.
Oracle était, il a quelques années, le produit le plus aboutis et surtout le plus fiable. Quand t'es dans une grosse boite, si t'as le moyen, tu les mets sur la fiabilité. Et puis après pour changer, si tu utilise du spécifique, ben t'es un peu mal barré.
Il faut re-coder, re-tester, re-mettre en prod et surtout prendre le risque de modifier un logiciel qui marche.

Après à titre perso, j'ai déjà eu des problèmes avec Oracle et avec PG (et MySQL bien sûr). Pas de jaloux!
Par contre il faut avouer que les problèmes sous Oracle sont plus rare, enfin était plus rare. A voir PG à rattrapé entièrement sont retard ou pas.

[escartefigue]

Après à titre perso, j'ai déjà eu des problèmes avec Oracle et avec PG (et MySQL bien sûr). Pas de jaloux!

Oui mais lesquels ? fonctionnalités manquantes ? fiabilité en défaut ? failles de sécurité, résistance insuffisante à la charge...

[Olivier Famien]

La version finale de PostgreSQL 9.6 est disponible
avec le parallélisme des requêtes, de nouvelles options pour la réplication synchrone et bien d’autres améliorations

Comme annoncé il y a quelques jours, la version finale de PostgeSQL 9.6 est disponible. Sans surprise, on retrouve le parallélisme des requêtes comme cela avait été déjà mis en œuvre dans la version release candidate.

Généralement, lorsque vous disposez de bases de données relativement petites, les requêtes s’exécutent sans difficulté. Mais lorsque les bases de données croissent afin d’atteindre des tailles impressionnantes, l’exécution des requêtes peut retourner des résultats dans un temps non négligeable.

Avec le parallélisme des requêtes, les administrateurs et les utilisateurs des bases de données pourront attaquer leurs bases avec plus de vélocité. Pour pouvoir tenir ses promesses, le parallélisme active l’utilisation de tout ou une partie des cœurs du processeur qui se trouve sur le serveur qui héberge la base de données afin de renvoyer les résultats plus rapidement.

Selon l’équipe de PostgreSQL, cette fonctionnalité permet d’espérer des gains de performances importants lors de l’exécution des requêtes sur les gros volumes de données.

Par ailleurs, vu que cette fonctionnalité fait ses premiers pas au sein de PostgreSQL, il faut savoir qu’il ne sera pas possible de l’utiliser pour toutes les opérations dans les requêtes. Seuls le parcours séquentiel, les agrégats et les jointures sont concernés par le parallélisme des requêtes.

En plus du parallélisme des requêtes qui a trouvé une place de choix dans cette version 9.6 de PostgreSQL, deux nouvelles options ont été également ajoutées à la réplication synchrone de PostgreSQL. La première est la possibilité de configurer des groupes de réplication synchrone. La seconde est que le mode « remote_apply » crée une vue plus cohérente des données sur les différents nœuds. Ces fonctionnalités permettent de maintenir des lectures cohérentes de données sur les nœuds d’un cluster de bases de données.

Autres améliorations qui pourront être bientôt utilisées dans PostgreSQL, c’est le pilote de fédération entre les bases de données PostgreSQL, postgres_fdw, qui a été doté de nouvelles fonctionnalités afin d’exécuter du travail sur les serveurs distants. Plus explicitement, cette fonctionnalité permet à PostgreSQL d’externaliser les tris, les jointures et les mises à jour afin de répartir les charges de travail sur plusieurs serveurs. L’équipe de PostgreSQL compte l’ajouter assez bientôt aux autres pilotes de PostgreSQL déjà existants.

Dans cette nouvelle version de PostgreSQL, il est maintenant possible d’effectuer des recherches par phrase en utilisant la recherche plein texte du système de gestion de bases de données relationnelles et objet.

A côté de toutes des nouvelles fonctionnalités, plusieurs autres améliorations ont été également ajoutées à PostgreSQL 9.6, comme :

• l’amélioration des réplications, des agrégats des tris et des procédures stockées ;
• l’utilisation optimale des ressources matérielles lorsque PostrgreSQL 9.6 est installé sur des noyaux Linux récents ;
• l’amélioration de VACUUM lors du traitement des grosses bases de données ;
• l’intégration de nouvelles vues et fonctions : pg_stat_wal_receiver, pg_visibility, pg_config, pg_blocking_pids, pg_notification_queue_usage ;
• la prise en charge de Wait Event ;
• le support des installations des extensions en cascade ;

Télécharger PostgreSQL 9.6

Source : PostgreSQL

Et vous ?

Avez-vous testé la dernière version de PostgreSQL ? Comment la trouvez-vous ?

Voir aussi

La Rubrique PostgreSQL, Forum PostgreSQL, Cours et tutoriels PostgreSQL, FAQ PostgreSQL

[Invité]

PG est solide et vaut largement Oracle et MSSQL pour des utilisations classiques. Cependant, une avancée majeure serait dans le domaine du partionnement de données. Là, on est dans la vraie prod, ça compte.
Actuellement, le partionnement est possible en définissant des héritages entre tables. Pour moi, c'est un hack, là où il faudrait une vraie fonctionnalité comme mentionne SQLPro. Et c'est lourd à mettre en oeuvre si on compare la fonctionnalité équivalente de MSSQL qui est vraiment bien pensée. Le partionnement se définit au niveau de la table et c'est simple à mettre en oeuvre (disponible uniquement en version Entreprise bien sûr).
Ce n'est pas un détail, dès que les données passent un certain volume pour des données "historiques", comme des commandes par exemple, l'existence d'un partionnement est discriminant pour les temps de requêtage.
Egalement, PG devrait se doter d'un outil Profiler à la MSSQL. C'est un outil très précieux pour un DBA.
Comme souvent en open source, des qualités techniques très sûres mais un manque de vision qui handicape l'adoption par rapport aux solutions commerciales.

[Chauve souris]

Décidément je n'ai pas de chance avec les nouveautés : MySQL qui ne se préoccupe nullement de où on installe programme et données (tout dans un tas sur C:\Program Files). PHP 7.0.1 qui refuse de s'installer sur IIS de Windows Server 2012-R2. Dans le cas du dernier PostgreSQL Stack Builder 4.0 plante à la fin des téléchargements et le nouveau pgAdmin 4 ne veut causer qu'en anglais. Et la version 3 se limite à la version 9.5 de PostgreSQL.

Mais il va bien y en avoir un dans la docte assemblée qui va me dire que c'est l'interface chaise clavier ce qui, soit dit en passant, est la dernière mode pour envoyer bouler, sans un mot d'explication, un qui relate un truc qui ne fonctionne pas ou mal. Pas seulement sur developpez.net, d'ailleurs. J'ai même eu droit à la version lapidaire dans le plus pur style linuxien : ICC. Sur le moment je n'avais pas compris car, pour moi, ICC c'est une abréviation médicale, comme LCR qui signifie nullement "Ligue Communiste Révolutionnaire". Effectivement j'avais eu de l'insuffisance cardiaque congestive (ICC donc) suite à une attaque de dengue, mais je ne papote pas sur mes problèmes de santé sur developpez.net...

[Chauve souris]

Ayé ! J'ai trouvé le gag de Stack Builder 4.0. Bien qu'il donne toutes les apparences windowiennes du coma dépassé (message "Ce programme ne répond plus") et la fenêtre passant au blanc spectral, il n'est pas si mort que ça. Voyant qu'il y avait une activité réseau sur le modem je lance CurrPorts (un petit utilitaire indispensable) qui m'indique une connexion établie sur un site postgresql. Téléchargement un peu lent, surtout dans mon pays de sauvages, puis, une fois celui-ci terminé, Stack Builder sort de son cercueil et propose de faire les installations.

PostgreSQL et ses éléphanteaux d'utilitaires sont bien élevés : à chaque fois ils demandent où on veut mettre les programmes. Pas comme MySQL que je n'aime pas beaucoup mais l'excellent freeware Filmotech de gestion de collection de films fonctionne avec lui.

Il n'y a plus qu'à espérer que des courageux traducteurs s'occupe de pgAdmin version 4...

[SQLpro]

Ayé ! J'ai trouvé le gag de Stack Builder 4.0. Bien qu'il donne toutes les apparences windowiennes du coma dépassé (message "Ce programme ne répond plus") et la fenêtre passant au blanc spectral, il n'est pas si mort que ça. Voyant qu'il y avait une activité réseau sur le modem je lance CurrPorts (un petit utilitaire indispensable) qui m'indique une connexion établie sur un site postgresql. Téléchargement un peu lent, surtout dans mon pays de sauvages, puis, une fois celui-ci terminé, Stack Builder sort de son cercueil et propose de faire les installations.

PostgreSQL et ses éléphanteaux d'utilitaires sont bien élevés : à chaque fois ils demandent où on veut mettre les programmes. Pas comme MySQL que je n'aime pas beaucoup mais l'excellent freeware Filmotech de gestion de collection de films fonctionne avec lui.

Il n'y a plus qu'à espérer que des courageux traducteurs s'occupe de pgAdmin version 4...

PgAdmin 4 fonctionne pas trop mal avec la 9.6 sous Windows

A +

[alassanediakite]

Salut

PgAdmin 4 fonctionne pas trop mal avec la 9.6 sous Windows

A +

PAS TROP MAL! c'est vrai...

• absence du mode graphique pour les requêtes
• dans la restauration, impossible de choisir le mode "répertoire"
• dans le nœud table->triggers->trigger, impossible d’accéder à la fonction trigger
• la sauvegarde est impossible, elle rame et quand on l'arrête on reçoit une erreur due au format utf. Ce qui est étrange, c'est que je l'ai fait avec pgAdmin 3 mais en utilisant les exécutables de pg 9.6
• l'installation en mode web est un champ de mine que j'ai pas encore franchi.

Personnellement, j'ai choisi PostgreSQL en grande partie à cause de pgAdmin (cela se comprend, je suis développeur ). Donc pour le moment je continue (en production) avec la 9.5 en attendant le bon fonctionnement de pgAmin 4.: (sinon pgAmin 3 ne râle pas trop sur la 9.6)
@+

[alassanediakite]

Salut

... L’équipe de PostgreSQL compte l’ajouter assez bientôt aux autres pilotes de PostgreSQL déjà existants.

Parlant de postgres_fdw, cela me semble une incompréhension.
A la date d'aujourd'hui, postgres_fdw est le pilote le plus suivi par l'équipe de développement.
Peut-être s'agit-il d'une intégration de postgres_fdw dans le CORE (directement dans le code) et ne plus en faire une extension comme c'est le cas actuellement.
@+