IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration PostgreSQL Discussion :

Nouvel article : comparaison des solutions de partitionnement PostGreSQL/SQL Server


Sujet :

Administration PostgreSQL

  1. #1
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut Nouvel article : comparaison des solutions de partitionnement PostGreSQL/SQL Server
    A lire : http://blog.developpez.com/sqlpro/p1...araison-postg/

    Contenu :

    1 - LE PRINCIPE DU PARTITIONNEMENT
    2 - L'EXEMPLE
    3 - TECHNIQUE DU PARTITIONNEMENT
    3 - LA SOLUTION POSTGRESQL
    PARTITIONNEMENT DE TABLE version PostGreSQL - PREMIÈRE CONCLUSION
    4 - LA SOLUTION MS SQL SERVER
    PARTITIONNEMENT DE TABLE version MS SQL Server - PREMIÈRE CONCLUSION
    5 - MANIPULER LES DONNÉES D'UNE TABLE PARTITIONNÉE
    5.1 - les insertions
    5.2 - Les extractions
    5.3 - Les suppressions
    5.4 - les modifications
    6 - LA VIE D'UNE TABLE PARTITIONNÉE
    6.1 - ajouter un index
    6.2 - Ajouter une colonne
    6.3 - Ajout d'une clef
    6.4 - Ajout d'une contrainte de validation
    6.5 - Ajout d'une contrainte d'intégrité
    7 - PARTITIONNEMENT MULTICOLONNE
    8 - CONCLUSION PARTITIONNEMENT PostGreSQL vs MS SQL Server

    Vos avis, vos commentaires seront appréciés.

    Merci
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  2. #2
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut

    Très intéressant et très complet ton article
    Le peu que j'avais testé du partitionnement sous Postgresql m'avait amené à la même conclusion que toi : une usine à gaz difficile à maintenir et impensable dans un environnement de production

    Pour compléter ton article, tu aurais aussi pu parler des performances en insertion : j'avais fait il y a quelques années un bench entre Oracle 10g et Postgresql 8.2, et pour une boucle d'insert ligne à ligne dans une table partitionnée, c'était 2 fois plus long sous Postgresql (sans doute à cause de tous les triggers et contraintes à vérifier à chaque insert)
    Ca pourrait être intéressant de comparer les temps entre Postgresql et SQL Server

    Egalement pour aller plus loin sur les plans d'exécution, sous Postgresql pour que le plan d'exécution ne lise que la bonne partition (et pas toutes les autres), il faut faire un filtre direct sur la table (ex : "where col_date = '2010-01-05'").
    Mais dès l'instant où le filtre sur ta clé de partitionnement est issu d'une condition de jointure, ça ne marche pas la plupart du temps, et Postgresql parcourt toutes les partitions.
    Exemple avec "table1" partitionnée par mois sur col_date et une requête du style "where table1.col_date = table2.col_date and table2.col_date = '2010-01-05'" : Postgresql 8.2 parcourt toutes les partitions de "table1" et non pas seulement celle correspondante à janvier 2010
    Alors qu'Oracle (et aussi SQL Server j'imagine) est capable par association d'en déduire table1.col_date='2010-01-05' et de ne lire que la partition de janvier 2010
    J'ai rencontré plusieurs fois ces problèmes de mauvais plans d'exécution en Postgresql 8.2, je n'ai pas testé si c'était toujours le cas dans les dernières versions

    Très bon article en tout cas
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Peut tu.. ou puis-je... mettre tes judicieuse remarques directement dans l'article ? ça aidera d'autres personnes qui mettent en place cela dans PG...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    Bien sûr, pas de droits d'auteur entre nous !
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Un coup à boire un de ces soirs alors....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Réponses: 0
    Dernier message: 10/10/2011, 03h31
  2. [info - SQLpro] - nouvel article : probématique des NULL
    Par SQLpro dans le forum Décisions SGBD
    Réponses: 1
    Dernier message: 17/09/2004, 10h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo