Sortie de PostgreSQL V7.3

Posté par matiasf le 01 décembre 2002 à 16:00. Modéré par Benoît Sibaud.

Étiquettes :

déc.

2002

PostgreSQL qui est considéré comme le plus évolué des gestionnaires de base de données open source vient de sortir la version 7.3.

Parmi les nouveautés on trouve :
- schémas
- fonction de table
- traçage des dépendances
Parmi les nouveautés on trouve :
- schémas :
Les schémas permettent à des utilisateurs de créer des objets dans leur propre espace de nom. Ainsi deux personnes ou applications peuvent avoir des tables avec le même nom.

- fonction de table :
Il est maintenant beaucoup plus facile d'employer des fonctions renvoyant un tableau. Vous pouvez appeler une telle "fonction de table" dans la clause "SELECT FROM" d'une requête. Le retour de la fonction est traité comme un tableau.

- traçage des dépendances :
PostgreSQL enregistre maintenant des dépendances entre objets ce qui permet des améliorations dans beaucoup de secteurs. La requête "DROP" supporte maintenant "CASCADE" ou "RESTRICT" pour contrôler si les objets dépendants doivent également être supprimés.

Pour ceux migrant d'une ancienne version de PostgreSQL un dump/restore est nécessaire (ne supprimez pas votre installation actuelle sans avoir réalisé un pg_dump !). Lisez avec attention la section "Migration to version 7.3" de la "release notes".

Des paquets rpm seront disponibles dans peu de temps.

Aller plus loin

L'annonce (3 clics)
Release notes (3 clics)
PostgreSQL (2 clics)
Téléchargement (2 clics)
Projects relatifs à PostgreSQL (3 clics)

# Re: Sortie de PostgreSQL V7.3

Posté par Victor Lopes le 01 décembre 2002 à 17:29. Évalué à 2.

Je viens de la tester :-)
Pour la recompilation sur un vieux linux 2.0.38 pas de problèmes :-)

Par contre :-(, là ou je suis un peu déçu à première vue et qui m'a fait
faire machine arrière vers la version 7.2.3 c'est la performance moindre par rapport aux version 7.2.

J'ai une base de plus de 400000 enregistrements et j'ai senti une
différence importante. C'est vraiment plus lent ! :-(
La ou j'avais une requête qui prenait 15 s pour s'executer la c'est près
1m 30s pour s'executer.

De plus j'ai du modifier quelques requêtes qui utilisaient la fonction
datetime qui a disparu en version 7.3. Ce n'est que mieux car cela
simplifie ma requête au niveau de l'écriture...

Je n'ai pas encore investigué et notamment en comparant les plans
d'exécution pour expliquer le pourquoi mais pour moi pour l'instant
je préfère rester en version 7.2.3 qui a mon sens malgré les
nouvelles fonctionnalités apportées et quand même beaucoup
plus rapide.

@+ piaff
- [^] # Re: Sortie de PostgreSQL V7.3
  
  Posté par Anonyme le 01 décembre 2002 à 18:00. Évalué à 2.
  
  > La ou j'avais une requête qui prenait 15 s pour s'executer la c'est près
  1m 30s pour s'executer.
  
  Problèmes d'indexes?
  - [^] # Re: Sortie de PostgreSQL V7.3
    
    Posté par Nÿco (site web personnel) le 01 décembre 2002 à 18:59. Évalué à 1.
    
    Muhahaha, t'es trop fort ! ;-)
    
    Problème type :"avant ça marchait plus vite..."
    Réponse type : "les zindexes petit, les zindexes..."
    
    Oué, il a raison... mais un peu plus généralement, tu as migré des données, alors avant d'accuser la nouvelle version, accuse ta migration... non ?
    
    PS Zorel : ça a bien changé parait-il là-bas... ;-)
    - [^] # Re: Sortie de PostgreSQL V7.3
      
      Posté par Anonyme le 01 décembre 2002 à 19:09. Évalué à 0.
      
      MAICHANT! Chuis pas DBA moi j'te rappelle.
      
      PS Ils ont viré Accidenture?
      - [^] # Re: Sortie de PostgreSQL V7.3
        
        Posté par Nÿco (site web personnel) le 01 décembre 2002 à 19:21. Évalué à 1.
        
        PS : (merde, a pu messages privés... ben non, juste réduit le nombre... par 3 ! y'a la v2 en route, l'abandon de l'ancien système en question... mais toujours la main-mise du sus-cité sur tous les autres projets pas forcément connexes... )
- [^] # Re: Sortie de PostgreSQL V7.3
  
  Posté par matiasf le 02 décembre 2002 à 00:44. Évalué à 3.
  
  > De plus j'ai du modifier quelques requêtes qui utilisaient la fonction datetime qui a disparu en version 7.3.
  
  Il y a l'option --enable-integer-datetimes pour ./configure. Je ne sais pas si çà peut aider.
  
  > je préfère rester en version 7.2.3
  
  Ce qu'il faut espére est que la version 7.3.3 soit aussi au point que la 7.2.3...
- [^] # Re: Sortie de PostgreSQL V7.3
  
  Posté par Jean-Paul ARGUDO (site web personnel) le 03 décembre 2002 à 09:46. Évalué à 1.
  
  Un peu tard pour répondre, je recconnais..
  
  Mais ton pb m'interpelle. Peut-on en savoir plus sur ton probleme? Je trouve cela très bizzare. La version 7.3 a de meilleures perfs encore au niveau global que la 7.2.
  
  Ca m'interresserait grandement que tu mettes ici les explain plan de la requete. Celui de la 7.2 et celui de la 7.3
  
  Enfin, je trouve que c'est domage de descendre une release parceque tu as eu un souci pontuel sur une recette dans une base. C'est pas franchement honnête je pense et c'est manquer un peu de respect pour le travail formidable de l'équipe de PG.
  
  Cordialement,
  - [^] # Re: Sortie de PostgreSQL V7.3
    
    Posté par matiasf le 03 décembre 2002 à 15:40. Évalué à 1.
    
    > Enfin, je trouve que c'est domage de descendre une release
    > c'est manquer un peu de respect pour le travail formidable de l'équipe de PG
    
    Je ne croix pas que c'est son intention. Il a un problème de perfo et indique qu'il va se pencher sur la question. Il a aussi quelques problèmes liés à la suppression de datetime (problème qu'il a corrigé). Il n'en fait pas reproche, il le constate uniquement.
    
    Il faut pas oublié que les utilisateurs d'un logiciel (semble-t-il de longue date dans ce cas) ne vont pas descendre le logiciel pour le plaisir. Néanmoins il doit pouvoir faire part de ses déconvenus. Et c'est uniquement ce qu'il a fait.
    
    PS : j'aime bien PostgreSQL.
# Re: Sortie de PostgreSQL V7.3

Posté par Anonyme le 01 décembre 2002 à 18:06. Évalué à 4.

PostgresQL est très bien, tout comme les autres BDD libres d'ailleurs (SAPdb, mysql, hypersonic, etc.) (tentons d'éviter les trolls).

Là où je travaille, Oracle Parallel Server a été choisi justement pour ses fonctions "Parallel Server". Le principe: 2 instances Oracle sur 2 machines différentes qui accèdent aux même données sur un disque partagé.

Je ne connais malheureusement aucune BDD libre qui ait cette fonctionnalité. Quelqu'un aurait plus d'infos que moi?
- [^] # Re: Sortie de PostgreSQL V7.3
  
  Posté par Nÿco (site web personnel) le 01 décembre 2002 à 19:18. Évalué à 3.
  
  (allez, rajoutons LEAP http://leap.sourceforge.net/(...) et Firebird http://sourceforge.net/projects/firebird(...) anciennement Borland/inprise Interbase)
  
  Oué, je suis aussi intéressé par cette question... que je tente d'élargir : n'existe-t-il pas d'outil(s) tiers qui puisse "paralléliser" (ou presque...) les RDBMS et/ou les applis qui tournent dessus (ou astuces kernel, filesystem, mémoire, etc...)
  - [^] # Re: Sortie de PostgreSQL V7.3
    
    Posté par Anonyme le 01 décembre 2002 à 19:38. Évalué à 2.
    
    Concernant les autres applis, pas mal de choses peuvent être mises en grappe (haute dispo, voir LVS). Concernant les BDD et autres applis du genre (j'ai pas d'exemples en tête, mais on devrait pouvoir trouver), le problème vient des structures des données gérées. Le noyau ne sait pas ce qu'il y a dedans, et je vois mal autre chose que le moteur de BDD prendre en charge le contenu.
  - [^] # Re: Sortie de PostgreSQL V7.3
    
    Posté par Sylvain Rampacek (site web personnel) le 01 décembre 2002 à 21:20. Évalué à 1.
    
    Je ne connaissais pas FireBird, mais à première vue, c'est plus un fork de Borland Interbase à partir de la libération du code de Interbase 6, non ?
    
    Car sur le site de Borland, ils développent toujours Interbase (version 7 actuellement http://www.borland.com/interbase/index.html(...) ).
- [^] # Re: Sortie de PostgreSQL V7.3
  
  Posté par aurelj le 01 décembre 2002 à 22:49. Évalué à 3.
  
  Pour les bases de données ou la majorité des accès se font en lecture, pgreplicator semble pouvoir être une solution ( http://pgreplicator.sourceforge.net/(...) ).
  
  Le principe n'est pas tout à fait le même. Avec pgreplicator, il y a 2 instances de PostgreSQL sur 2 machines différentes qui accèdent à 2 disques différent. A chaque écriture dans la base, les données sont répliquées sur l'autre serveur. C'est pour ça qu'il ne convient pas aux bases de données gérant autant d'écritures que de lectures.
  
  Ca ne vaut peut-être pas Oracle Parallel Server mais ca a le mérite d'exister.
  - [^] # Re: Sortie de PostgreSQL V7.3
    
    Posté par Anonyme le 01 décembre 2002 à 23:06. Évalué à 1.
    
    On a pas beaucoup d'écriture dans la base pour ce qu'on veux en faire. Mais les fonctionnalités ne sont pas les même en pgreplicator et OPS, donc pour vendre un remplacement, bonjour la galère.
    - [^] # Re: Sortie de PostgreSQL V7.3
      
      Posté par matiasf le 02 décembre 2002 à 00:32. Évalué à 2.
      
      > On a pas beaucoup d'écriture dans la base
      
      Je ne connais pas ton applis, mais l'utilisation de transaction améliore significativement les performances. Tu regroupes plusieurs requêtes d'écriture dans une transaction. Il y a ainsi moins d'appel à fsync().
      
      Pour améliorer de façon assez fabuleuse les performances en écriture de postgresql, tu peux désactiver sur le serveur PostgreSQL l'appel à fsync(). Par contre en cas de coupure de courant ou autre, tes données peuvent ne plus être cohérentes entre le serveur et le/les clients. Exemple :
      - Client : Demande une place pour le train Paris-Lyon
      - Serveur : retourne un numéro de place au client et écrit la réservation dans la base de donnée. La réservation sera définitivement écrite sur le disque dur une peu plus tard à la discrétion de l'OS.
      - Coupure de courant : La réservation n'avait pas encore été écrite sur le disque dur.
      - Retour courant : boot serveur.
      
      On a maintenant un client bien réel qui a acheté la place 20 du train Paris-Lyon alors que cette information n'est pas écrite en base de donnée. La place 20 peut maintenant être vendue une seconde fois...
      Si ton appli n'a pas ce type de problématique, que tu n'as pas de plantage et dispose d'un régulateur, alors tu peux envisager de désactiver l'appel à fsync().
  - [^] # Re: Sortie de PostgreSQL V7.3
    
    Posté par matiasf le 02 décembre 2002 à 01:11. Évalué à 2.
    
    pgreplicator ne fait pas tourné deux serveurs en parallèle (pas de répartition de charge). Chaque serveur a sa "vie". Mais pgreplicator permet de synchroniser les serveurs entre eux (Toutes les nuits, heures, à la demande, sur trigger, etc...).
    
    Néanmoins, c'est très interessant :
    1 - pour les bases de donnée "itinérantes"
    2 - pour avoir une copie à jour d'une serveur et opérationnel. çà permet d'avoir un backup toujour à jour.
    
    Je sais surement tester à la première occasion.
- [^] # Re: Sortie de PostgreSQL V7.3
  
  Posté par matiasf le 02 décembre 2002 à 00:13. Évalué à 2.
  
  > Le principe: 2 instances Oracle sur 2 machines différentes qui accèdent aux même données sur un disque partagé.
  
  Je m'interroge si ce type de fonctionnement est plus rapide qu'une simple machine multiprocesseur...
  En effet, un disque partagé c'est des communications (entre autre pour les verrouillages, vérification que le cache est à jour, etc...) via réseau. çà ressemble furieusement à une serveur et deux clients qui accèdent aux données. Sauf que dans ce cas, c'est les clients qui applique la "police" lors de l'accès aux donnée.
  
  Une solution plus classique et "facilement" réalisable sous Linux est :
  1 - un front-end pour répartir la charge
  2 - plusieur machines applicatives avec des clients base de donnée. Les programmes, script, etc peuvent être sur un lecture nfs.
  3 - un gros serveur (beaucoup de mémoire) de base de donnée.
  
  Le serveur PostgreSQL est adapté à une utilisation multi-cpu (mais je ne sais pas dans quelle mesure). En effet, à chaque connection d'un client, le postmaster crée un processus serveur qui répond à un client. Si plusieurs client, alors plusieurs serveurs.
  Voir ici pour une description pas très détaillée :
  http://www.fr.postgresql.org/users-lounge/docs/7.2/postgres/arch-pg(...)
  - [^] # Re: Sortie de PostgreSQL V7.3
    
    Posté par Anonyme le 02 décembre 2002 à 10:04. Évalué à 1.
    
    Tu sais, quand on a 2 machines Sun 6800 avec 16 proc et 16 Go de RAM, on se pose pas la question. La question est plutôt celle de la haute disponibilité des applis. On peut crasher une base sans faire bouger l'autre. En théorie bien sûr, si l'appli client de la base supporte cela.
    - [^] # Re: Sortie de PostgreSQL V7.3
      
      Posté par matiasf le 02 décembre 2002 à 11:20. Évalué à 1.
      
      Bon, on peut déjà écarter le problème du pognon :-) .
- [^] # Re: Sortie de PostgreSQL V7.3
  
  Posté par jMax le 02 décembre 2002 à 10:31. Évalué à 2.
  
  IdealX a un projet de clustering de BDD qui va dans ce sens :
  http://www.idealx.org/prj/index.en.html#idx-clust(...)
  ...et en plus, ça tourne au GPL.
  
  Par ailleurs, PostgreSQL Inc. sponsorise eRServer un outil de réplication de base :
  http://www.erserver.com/(...)
  
  Ca ne fait pas exactement de la parrallélisation, mais c'est toujours intéressant à connaître.
# Re: Sortie de PostgreSQL V7.3

Posté par blackshack le 02 décembre 2002 à 10:30. Évalué à 2.

euh ne serait il pas mieux de faire un pg_dump_all pluto qu'un pg_dump?
enfin je dis ca je dis rien
- [^] # Re: Sortie de PostgreSQL V7.3
  
  Posté par matiasf le 02 décembre 2002 à 11:19. Évalué à 2.
  
  euh ne serait il pas mieux de faire un pg_dumpall pluto qu'un pg_dump_all?
  enfin je dis ca je dis rien

Suivre le flux des commentaires

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