PostgreSQL 9.0 est sorti

Posté par (page perso) . Modéré par tuiu pol.
49
20
sept.
2010
Base de données
PostgreSQL est sorti ce lundi 20 septembre en version 9.0.
Pour mémoire, PostgreSQL est un système de gestion de base de données relationnel-objet qui se veut le plus performant possible tout en respectant les standards SQL au maximum, la licence du code source est de type MIT.
Cette dernière version apporte plus de 200 améliorations (nouvelles fonctions, nouvelles commandes, ajout d'options...) et permet de migrer à partir d'une base 8.3 ou 8.4.

La principale nouveauté est la réplication intégrée par défaut, qui était une demande importante de la part des utilisateurs.
Même si elle est limitée à un seul maître et plusieurs esclaves, ceci devrait réjouir beaucoup d'utilisateurs.
Les autres nouveautés importantes sont détaillées en seconde partie de dépêche.
  • La gestion des droits est améliorée grâce à la gestion des changements multiples par les commandes GRANT/REVOKE IN SCHEMA, des permissions peuvent aussi être posées sur les Blobs
  • Du côté des langages de script : l'assertion DO gère les blocs de code anonymes, PL/Python intègre l'Unicode et Python 3, PL/pgSQL est installé par défaut, PL/Perl continue de s'améliorer.
  • De nouveaux types de requête sont disponibles : l'exécution de SELECT FOR UPDATE/SHARE peut maintenant retourner un nombre de lignes prédictible avec LIMIT, les requêtes de fenêtrage peuvent utiliser CURRENT ROW et les options ROWS n PRECEDING/FOLLOWING.
  • Les Triggers ont désormais une option WHEN qui permet de tester une condition à chaque fois que le trigger est appelé, ceci permet un gain de performance par rapport à une condition dans le code. La prise en charge de la norme SQL s'améliore encore avec l'introduction des triggers sur les colonnes.
  • Les clefs primaires peuvent être désormais mises à jour en masse d'un seul coup.
  • La commande EXPLAIN qui permet de détailler l'exécution d'une requête (utilisation d'un index ou non, nombre de lignes prises en compte...) offre désormais des formats de sorties en JSON, XML ou YAML.
  • La sécurité n'est pas non plus mise de côté avec l'introduction de l'authentification par RADIUS, la prise en charge de LDAP a été améliorée et un nouveau module, passwordcheck, a été introduit afin de tester la force d'un mot de passe
  • # En complément

    Posté par . Évalué à  10 .

    Pour ceux qui veulent en savoir un peu plus (et en français):
    http://blog.postgresql.fr/index.php?post/2010/09/20/Sortie-d(...)
    • [^] # Re: En complément

      Posté par . Évalué à  4 .

      Et l'annonce officielle est ici (avec les liens vers tous les documents intéressant : guide de la version, notes de version, pages de téléchargement...)
      http://www.postgresql.org/about/news.1235
    • [^] # Re: En complément

      Posté par (page perso) . Évalué à  5 .

      Et pour en savoir encore plus sur les nouveautés de PostgreSQL, et toujours en français, je propose cette page :
      http://blog.postgresql.fr/index.php?post/2010/06/16/Pr%C3%A9(...)

      Le moins que l'on puisse dire, c'est que ça évolue bien !
      • [^] # Re: En complément

        Posté par (page perso) . Évalué à  4 .

        Contraintes d'intégrité, triggers, réplication... Les cas où l'utilisation d'Oracle seront justifiés vont se faire de plus en plus rare !

        Les SGBD Postgresql et Ingres sont issus de la même origine et sont maintenant tous les deux libres : est-ce qu'il existe une comparaison récente de ces deux logiciels ?
        • [^] # Re: En complément

          Posté par (page perso) . Évalué à  3 .

          Les cas où l'utilisation d'Oracle seront justifiés vont se faire de plus en plus rare !

          Il me semblait que l'utilisation d'Oracle était plus liée à des raisons de performance que de fonctionnalité. (Mais ce n'est qu'une impression.)

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: En complément

            Posté par . Évalué à  7 .

            Et surtout parce que :

            "L'éditeur nous impose d'utiliser une base oracle"
          • [^] # Re: En complément

            Posté par (page perso) . Évalué à  5 .

            Oui c'est un impression.

            Bcp d'entreprises utilisent Oracle parce que ca coute, donc ca rassure !
            • [^] # Re: En complément

              Posté par (page perso) . Évalué à  2 .

              Bcp d'entreprises utilisent Oracle parce que ca coute, donc ca rassure !

              Je parlais des arguments rationnels.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: En complément

                Posté par . Évalué à  5 .

                Le problème n'est pas d'avoir un argument rationnel à nos yeux mais de convaincre nos responsables...

                Il y a 3 vérités :
                Ta vérité
                Ma vérité
                et la Vérité

                Aujourd'hui, si je propose d'utilise Postgresql, j'aurais droit aux réponses suivantes :

                - nos DBAs sont formés sous Oracle
                - on a le support Oracle
                - Oracle, c'est plus mieux, la preuve, toutes les grosses DSI l'utilisent.
                - On a déjà Oracle, pourquoi changer?
                • [^] # Re: En complément

                  Posté par (page perso) . Évalué à  5 .

                  Aujourd'hui, si je propose d'utilise Postgresql, j'aurais droit aux réponses suivantes :

                  C'est toujours les mêmes raisons évoquées quand on change de logiciel, mais pgsql ne peut rien faire contre ça, par contre s'il peut déjà lutter contre ceux qui sont corrigibles, c'est déjà ça comme arguments en plus.

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: En complément

            Posté par (page perso) . Évalué à  10 .

            Ce n'est qu'une impression. Et c'est une chose vérifiable, la plupart des utilisateurs et des DBA que j'ai formé ou rencontré au cours de mes différentes interventions ou formations m'ont fait le retour inverse : PostgreSQL est bien plus performant qu'Oracle sur bien des aspects.

            Par contre un point important est de bien définir ce qu'est la performance. Lorsque j'en parle avec ces personnes, la performance a trois visages :

            - La performance de réponse à une requête : PostgreSQL est jugé plus performant dans la plupart des cas
            - La performance à la prise en main, ce qui comprend l'installation, la mise en œuvre d'une manière générale : PostgreSQL est jugé également plus simple et plus rapide à maîtriser
            - La performance à la résolution de problèmes (troubleshooting) et au tuning : comment résoudre un problème posé par PostgreSQL, comment se sortir des situations de non performances etc. PostgreSQL est bien outillé pour fournir les informations nécessaires au tuning et à la gestion des cas d'erreur. De ce point de vue, Oracle fait plutôt appel à l'expérience et à des recettes de tuning. L'outillage idoine d'Oracle est effectivement plus évolué de ce point de vue.

            Donc dire qu'Oracle est choisi pour sa performance est une phrase gratuite (pas forcément la tienne d'ailleurs) qui cache souvent une méconnaissance de PostgreSQL d'une part et peut être aussi, d'autre part, une sorte de mauvaise foi de certains DBA qui, sous le couvert de formations coûteuses, ne veulent pas dévoyer leurs compétences/rayon d'action qu'ils ont acquis à grand prix. (comme quoi, il est aussi possible de troller dans l'autre sens). Cette dernière remarque ne s'applique qu'à une population de moins en moins grande de DBA par ailleurs.


            Pour finir, là où Oracle a encore des avantages, c'est l'étendue fonctionnelle. Certes, la différence d'étendue fonctionnelle entre PostgreSQL et Oracle tend à se réduire. Il est donc plus performant fonctionnellement (ou pourra parler de richesse).

            Oracle dispose aussi d'offres de support (coûteuses) intégrées. Mais l'offre de service PostgreSQL tend à se diversifier et nous trouvons dans le monde et en France de plus en plus de société prêtes à s'engager et à s'impliquer assez profondément dans la communauté et dans le code même du moteur. On peut dire que l'offre de service et de support PostgreSQL est en train de s'épanouir et que la recherche de prestataire est maintenant une chose aisée pour un grand compte par exemple.
            • [^] # Re: En complément

              Posté par . Évalué à  2 .

              > - La performance de réponse à une requête : PostgreSQL est jugé plus performant dans la plupart des cas

              Y compris sur les grosses bases de données?

              [ je ne trolle pas: je me renseigne ]
            • [^] # Re: En complément

              Posté par (page perso) . Évalué à  6 .

              La volonté de « standardisation » est aussi un frein à l'adoption de PostgreSQL. Je travaille actuellement pour une grande entreprise qui a des centaines de bases installées (au moins une par application).

              MySQL est depuis quelques temps au référentiel technique interne, et on commence à en déployer, lorsque la volumétrie estimée est faible. Toutes les autres sont systématiquement en Oracle, même si d'un point de vue strictement technique 95 % (à vue de nez) tourneraient très bien avec PostgreSQL.

              La raison invoquée est que les exploitants, les experts, les prestataires, etc. ne connaissent guère qu'Oracle.

              De plus, les tarifs d'Oracle sont opaques, mais une grande entreprise arrive à négocier des licences annuelles forfaitaires, telles qu'une dizaine de bases Oracle en plus ou en moins ne coûte rien : pour que pg puisse rivaliser sur le prix, il faudrait qu'un nombre très important de bases soient migrées sur une même période, ce qui reste très improbable...
            • [^] # Re: En complément

              Posté par (page perso) . Évalué à  2 .

              > - La performance à la résolution de problèmes (troubleshooting) et au tuning : comment
              > résoudre un problème posé par PostgreSQL, comment se sortir des situations de non
              > performances etc. PostgreSQL est bien outillé pour fournir les informations nécessaires au
              > tuning et à la gestion des cas d'erreur. De ce point de vue, Oracle fait plutôt appel à
              > l'expérience et à des recettes de tuning. L'outillage idoine d'Oracle est effectivement plus
              > évolué de ce point de vue.

              Il y a des probes DTrace/SystemTap dans Oracle ?

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

              • [^] # Re: En complément

                Posté par (page perso) . Évalué à  2 .

                Il y a des probes DTrace/SystemTap dans Oracle ?

                <mode chieur>Oui il y en a dans Oracle Solaris ;-)</mode chieur>

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

  • # LISTEN/NOTIFY

    Posté par . Évalué à  4 .

    Pending events are now stored in a memory-based queue rather than a table.

    youpi! Ça me faisait toujours flipper ces LISTEN zombies qui traînaient quand tu redémarrais une base. Un jour j'ai compris qu'il fallait envoyer un NOTIFY dessus pour qu'ils disparaissent, c'est assez inhabituel en info qu'une fonction sensée agir fasse le ménage d'elle même.
    Ça sera plus propre maintenant.
  • # dispo dans Debian

    Posté par (page perso) . Évalué à  5 .

    Pour information, Postgresql 9.0 est déjà disponible dans Debian Sid (Squeeze étant gelée).
    http://packages.debian.org/sid/postgresql-9.0
  • # Au revoir liberté

    Posté par . Évalué à  -10 .

    Cette fois ci : on y est : Une résolution du Parlement européen appelle à davantage de contrôle sur internet sera voté mercredi, résolution lancé rapidement par un émissaire de sarkozy.

    http://translate.google.com/translate?hl=fr&sl=en&tl(...)

    Au revoir la culture libre ? les logiciels libres ?

    Comme le dit la fsf, et l'april.
    • [^] # Re: Au revoir liberté

      Posté par (page perso) . Évalué à  7 .

      Ce message n'aurait-il pas pu trouver une place plus pertinente dans les commentaires d'un autre journal ou dans un journal dédié ?
      Par ailleurs, pour ceux qui ne souhaitent pas faire saigner leurs yeux avec un traducteur automatique, voici le lien vers l'article original sur boingboing : [http://www.boingboing.net/2010/09/20/europeans-eu-parliam.ht(...)].
      Cet article est une alarme concernant le vote imminent du rapport Gallo au parlement européen. Il invite les lecteurs à contacter leurs représentants pour les informer des conséquences dramatiques que pourrait avoir l'adoption d'une telle infamie. On peut cependant légitimement se posé la question de la pertinence d'une telle action. Étant donné la large diffusion d'œuvres comme les romans les plus connus d'Orwell et d'Huxley, quel membre du parlement ne votera pas en toute connaissance de cause et responsabilité ?
    • [^] # Re: Au revoir liberté

      Posté par . Évalué à  1 .

      çà pue l'intox comme news.
  • # Contenu d'une base

    Posté par . Évalué à  3 .

    Je commence un projet qui va nécessiter un archivage d'une grande partie des données traitées. Le cahier des charges demande à ce que toutes les données archivées soient accessibles de la même manière que les données en cours de traitement.

    Je n'ai pas d'expérience dans le stockage systématique d'information en base de données.

    C'est viable de garder une base avec 2 ou 3 tables qui grossi perpétuellement ? (sans prendre en compte la capacité physique de stockage qui n'est pas un problème) ou l'application va s'écrouler d'un point de vu réactivité ? Il y a t'il une taille limite pour une table dans PostgreSQL ?
    PostgreSQL (même si rien ne garanti que c'est la solution qui va être gardée par mon décideur pressé) prévoit-il des techniques particulière pour ce genre d'utilisation de base de données ?

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Contenu d'une base

      Posté par (page perso) . Évalué à  4 .

      J'ai une expérience assez limitée dans le domaine mais :

      Maximum size for a database? unlimited (32 TB databases exist)
      Maximum size for a table? 32 TB

      http://wiki.postgresql.org/wiki/FAQ#What_is_the_maximum_size(...)

      Si tu as des indexes bien pensés, que le matériel est dimensionné correctement et que tu fais pas des requêtes trop louches, je vois pas pourquoi cela poserait des problèmes de performance quelque soit la taille de la table/base.

      A priori je verrais un stockage des données dans une série de tables (changement toutes les X semaines ou à chaque fois qu'on approche des 32 TB) avec une table à côté pour indexer dans quelle table se trouve quoi.

      Ça pourrait s'appliquer aussi bien à PostgreSQL que Oracle que MySQL que n'importe quelle autre db je pense.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

      • [^] # Re: Contenu d'une base

        Posté par . Évalué à  5 .

        A priori je verrais un stockage des données dans une série de tables (changement toutes les X semaines ou à chaque fois qu'on approche des 32 TB) avec une table à côté pour indexer dans quelle table se trouve quoi.

        PostgreSQL le fait tout seul : http://docs.postgresqlfr.org/8.1/ddl-partitioning.html
      • [^] # Re: Contenu d'une base

        Posté par . Évalué à  2 .

        Pour le dimensionnement du serveur c'est à quel niveau qu'il faut faire attention ?
        - performance des disques ?
        - capacité des disques ?
        - puissance de calcul ?
        - autre ?

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Contenu d'une base

          Posté par . Évalué à  2 .

          J'imagine que si ta base tient en RAM, les perf n'ont rien à voir avec une version au des accès disque en lecture sont nécessaire.

          J'imagine aussi que si tu as une seul requête qui demande le parcours de la base, tu es mort :)

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

  • # Un système de qualité

    Posté par (page perso) . Évalué à  10 .

    Postgres est LE projet qui me fait aimer les bases de données. Le système est incroyablement cohérent et solide. L'ergonomie du système est impressionnante, plus je l'utilise et plus je découvre de nouvelles fonctionnalités et petits détails qui facilitent l'utilisation. Pour moi, c'est là que Postgres se démarque:

    - Postgres fournit des fonctions stockées en place des procédures stockées. En plus des utilisations habituelles des procédures, les fonctions peuvent également être chaînées, utilisées au sein d'une requête pour retourner une table... Beaucoup plus pratique pour structurer et généraliser son code.

    - Postgres est la seule base à ma connaissance à fournir une excellente API cliente en C++, officielle (et donc maintenue), et moderne. Enfin un système utilisable sans avoir au préalable à passer une semaine à se casser la tête à coder un wrapper!

    - Postgres fournit un très bon client graphique, officiel (et donc maintenu lui aussi!), proposant entre autres une représentation graphique du plan de requête, ce qui est particulièrement pratique lorsque l'on a une requête géante à optimiser

    Au boulot, dès que j'ai à faire quelque chose d'un poil compliqué avec mes données, je copie tout le bazar depuis le gros serveur DB2 vers le Postgres installé en douce sur ma machine, et je me régale.

    Bravo à l'équipe Postgresql, et longue vie au projet!
  • # Y a pas qu'Oracle dans la vie...

    Posté par . Évalué à  2 .

    Je remarque que tout le monde ici compare PostgreSQL à Oracle, mais qu'en est-il vis-à-vis des autres, comme MS SQL Server ? Ou IBM DB2 ? Ou... ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.