Article: comparaison solutions partitionnement PostGreSQL / SQL Server

SQLpro · 10/10/2011 02:34:31

A lire : http://blog.developpez.com/sqlpro/p1037 … son-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

gleu · 10/10/2011 09:03:14

partitionnement

Drôle d'idée que de créer des règles. Il vaudrait mieux passer par des triggers, ce qui diminuerait très fortement le nombre de requêtes SQL à exécuter. Ça vous éviterait aussi de lancer quatre DELETE quand un seul suffit. De plus, l'UPDATE que vous faite n'a aucun intérête. Votre règle (par exemple R_U_MSR_AN2008) ne devrait avoir qu'un DELETE et un INSERT.

tablespace... sous PostGreSQL ou elle est embryonnaire

C'est voulu ainsi. PostgreSQL se base fortement sur le système qui l'héberge.

L'optimiseur est incapable de trouver directement tout seul comme un grand la partition adéquate... Mais c'est possible à condition de lui forcer la main en lançant préalablement la commande :
SET CONSTRAINT_EXCLUSION = ON;

Depuis quelques moments déjà (la 8.4, soit plus de trois ans), le constraint_exclusion faut 'partition' par défaut, ce qui fait qu'il n'y a rien à faire. À se demander quelle version de PostgreSQL vous testez.

Rappelons pour information que cette table ne peut contenir aucune ligne puisqu'un trigger l'y empêche. La scrutation de cette table est donc parfaitement inutile et fait perdre du temps de traitement !

Pour le savoir, il faudrait qu'il puisse comprendre le code du trigger, ce qui n'est pas possible. De plus, la scrutation d'une table vide est nulle.

À nouveau PostGreSQL semble perdu alors qu'il n'a qu'une seule partition à scruter. Le plan graphique est encore plus immonde :

Merci de ne pas confondre PostgreSQL et pgAdmin. pgAdmin est un outil d'administration graphique qui va afficher le plan graphique, PostgreSQL est le serveur. Et PostgreSQL n'est pas perdu.

Dans PostGreSQL, la nouvelle contrainte CHECK se propage dans les tables filles.

Vous voulez certainement dire qu'elle ne se propage pas.

Il faut bien constater que la mise en œuvre du partitionnement sous PostGreSQL est très complexe et quasi infaisable en production

C'est très loin d'être le cas. J'ai plusieurs clients qui les utilisent avec bonheur. Par contre, je suis bien d'accord que le partitionnement dans PostgreSQL n'existe pas. Il existe un moyen de contourner ce manque et il faut en connaître les avantages et les inconvénients. Ce n'est qu'un contournement.

Je trouve très adroit de votre part de comparer une fonctionnalité qui existe dans SQLServer et qui n'existe pas en natif dans PostgreSQL. Très fair-play.

Autre chose, vous dites ne pas avoir eu de réponses sur les forums où vous avez posé des questions sur le partitionnement. Je ne sais pas sur combien de forums vous avez posé la question mais 1. ce n'était pas ici, et 2. sur pgsql-sql, vous avez eu deux réponses, mais vu comment vous accueillez les réponses, ce n'est guère étonnant que vous n'ayez pas de réponses. Pour les curieux, voir http://archives.postgresql.org/pgsql-sq … g00006.php

Concernant les performances à la baisse, je ne vois aucun test de performance sur votre article. Uniquement (et c'est déjà bien) un test de la mise en place de cette fonctionnalité sur PostgreSQL et SQL Server.

Pour terminer il est extrêmement difficile de gérer les partitions au niveau du stockage.

Marrant ça, moi je fais un ALTER TABLE pour indiquer à la table fille son nouveau tablespace et c'est terminé.

Bref, encore un article à charge de la part de SQLpro, rien de bien nouveau sous le soleil.

kenrio · 10/10/2011 10:41:50

Juste pour info pourquoi s'obstiner à comparer mssql et postgresql ?

De mon point de vue, je connais bcp de dba mssql et aucun ne passera sur postgresql.

Donc je trouve ces comparaisons complètement useless, comparer postgresql et oracle à du sens mais mssql....

Dernière modification par kenrio (10/10/2011 10:42:10)

SQLpro · 10/10/2011 12:05:12

gleu a écrit :

Drôle d'idée que de créer des règles. Il vaudrait mieux passer par des triggers, ce qui diminuerait très fortement le nombre de requêtes SQL à exécuter. Ça vous éviterait aussi de lancer quatre DELETE quand un seul suffit. De plus, l'UPDATE que vous faite n'a aucun intérête. Votre règle (par exemple R_U_MSR_AN2008) ne devrait avoir qu'un DELETE et un INSERT.

C'est ce qui est montré dans l'aide en ligne à ce sujet : http://docs.postgresql.fr/8.2/ddl-partitioning.html
De plus passer par des déclencheurs ne réduit pas la complexité, il l'augmente vu qu'au lieu d'une règle il faut deux commandes :
- la création de la fonction trigger
- la création du trigger association la table et son événement et la fonction trigger.

tablespace... sous PostGreSQL ou elle est embryonnaire

C'est voulu ainsi. PostgreSQL se base fortement sur le système qui l'héberge.

Mais c'est bien dommage car l'intérêt majeur du partitionnement c'est le stockage physique ! Oracle qui s'installe sur de multiples plateformes propose une bonne gestion des espaces de stockage...

Depuis uelques moments déjà (la 8.4, soit plus de trois ans), le constraint_exclusion faut 'partition' par défaut, ce qui fait qu'il n'y a rien à faire. À se demander quelle version de PostgreSQL vous testez.

Petite erreur de ma part, c'est corrigé.

Rappelons pour information que cette table ne peut contenir aucune ligne puisqu'un trigger l'y empêche. La scrutation de cette table est donc parfaitement inutile et fait perdre du temps de traitement !

Pour le savoir, il faudrait qu'il puisse comprendre le code du trigger, ce qui n'est pas possible. De plus, la scrutation d'une table vide est nulle.

Oui, mais il aurait été plus simple de concevoir le système en permettant que les contraintes se propagent ou non de la table mère aux tables filles.
Il est d'ailleurs curieux de constater que la propagation des contraintes des tables en héritage est tantôt effectives pour certaines, tantôt non effectives pour d'autres.
Il aurait été plus intelligente soit de tout propager, soit de ne rien propager, soit de rajouter une option pour forcer la propagation au coup par coup ou globalement... Encore un point critique !

À nouveau PostGreSQL semble perdu alors qu'il n'a qu'une seule partition à scruter. Le plan graphique est encore plus immonde :

Merci de ne pas confondre PostgreSQL et pgAdmin. pgAdmin est un outil d'administration graphique qui va afficher le plan graphique, PostgreSQL est le serveur. Et PostgreSQL n'est pas perdu.

Certes, mais la complexité du plan textuel parle d'elle même !

Dans PostGreSQL, la nouvelle contrainte CHECK se propage dans les tables filles.

Vous voulez certainement dire qu'elle ne se propage pas.

À moins d'être idiot, je pense que vous vous trompez...
Démonstration :

CREATE TABLE T (C INT);

CREATE TABLE T1 () INHERITS (T);

ALTER TABLE T ADD CONSTRAINT K CHECK (C >= 0);

SELECT TABLE_NAME, CONSTRAINT_NAME, CONSTRAINT_TYPE 
FROM   INFORMATION_SCHEMA.TABLE_CONSTRAINTS
WHERE  table_name IN ('t', 't1');

TABLE_NAME   CONSTRAINT_NAME   CONSTRAINT_TYPE 
------------ ----------------- -----------------
t1            k                 CHECK
t             k                 CHECK

INSERT INTO T1 VALUES (-1);

ERREUR:  la nouvelle ligne viole la contrainte de vérification « t1 » de la relation « k »

Il faut bien constater que la mise en œuvre du partitionnement sous PostGreSQL est très complexe et quasi infaisable en production

C'est très loin d'être le cas. J'ai plusieurs clients qui les utilisent avec bonheur. Par contre, je suis bien d'accord que le partitionnement dans PostgreSQL n'existe pas. Il existe un moyen de contourner ce manque et il faut en connaître les avantages et les inconvénients. Ce n'est qu'un contournement.

Si le critère de partition est immuable (ce qui en pratique est souvent le cas, mais s'il y a des erreurs de saisie....) cela simplifie les choses.
Mon article compare les deux solutions (SQL Server vs PostGreSQL) et montre à l'évidence que le coût induit par la complexité de mise en œuvre est très largement en défaveur de PostGreSQL... Pour 5 partitions, 28 créations d'objets et plus de 50 requêtes SQL et cela sans une gestion des espaces de stockage efficace. Je pense que c'est un record. Même MySQL parait plus simples et plus avancé sur ce coup là. D'ailleurs les développeurs de PostGreSQL sont très conscient que cette méthode est mal foutue.. A lire : http://wiki.postgresql.org/wiki/Table_partitioning
Je ne conteste pas l'utilisation intéressante du partitionnement, j'y ai même consacré un papier : Partitionner vos tables pour améliorer les performances
Je ne doute pas non plus du bonheur de vos clients... Reste que la facture est élevée ! C'est d'ailleurs tout à votre avantage pour vendre du service...

Je trouve très adroit de votre part de comparer une fonctionnalité qui existe dans SQLServer et qui n'existe pas en natif dans PostgreSQL. Très fair-play.

Je ne suis pas adepte du consensus mou ni du politiquement correct. Lorsque je compare c'est sur le plan technique et fonctionnel. Que cela vous chagrine, je le conçoit, mais là on est dans les émotions et non plus dans le discours technique. Ma volonté n'est pas de démolir PG qui reste un bon SGBDR adapté à des bases de moyennes et grande tailles. PG possède même certaines avancées qui dépassent SQL Server. Je n'en citerais que quelques unes : l'héritage des tables, les fonctions de fenêtrage avec la gestion des fenêtres (Rows / Range), un SIG à la hauteur... Et SQL Server possède aussi quelques défaut comme cet horrible contrainte UNIQUE qui ne permet qu'un seul NULL !

Autre chose, vous dites ne pas avoir eu de réponses sur les forums où vous avez posé des questions sur le partitionnement. Je ne sais pas sur combien de forums vous avez posé la question mais 1. ce n'était pas ici, et 2. sur pgsql-sql, vous avez eu deux réponses, mais vu comment vous accueillez les réponses, ce n'est guère étonnant que vous n'ayez pas de réponses. Pour les curieux, voir http://archives.postgresql.org/pgsql-sq … g00006.php

Sauf que vous ne m'avez toujours pas montré d'exemple !

Concernant les performances à la baisse, je ne vois aucun test de performance sur votre article. Uniquement (et c'est déjà bien) un test de la mise en place de cette fonctionnalité sur PostgreSQL et SQL Server.

C'était le but : montrer la mise en œuvre. Mais on ne peut pas douter de performances moindre à la lecture de certains plans de requête. Attention : j'ai volontairement choisit l'angle mise en œuvre, pas celui de l'exploitation.
La plupart des requêtes bénéficieront du gain du partitionnement et il est extrêmement difficile de réaliser un benchmark comparatif au niveau des performances. Moi je n'en ais pas les moyens. Mon entreprise, [url=http://www.sqlspot.com/]SQL spot[url]n'a qu'un seul acteur, moi même ! Peut être pouvez-vous vous en occuper chez Dalibo. Je serais heureux de vous y aider, car j’apprécie les show PostGreSQL que vous faites et auquel je tente de participer régulièrement...

Pour terminer il est extrêmement difficile de gérer les partitions au niveau du stockage.

Marrant ça, moi je fais un ALTER TABLE pour indiquer à la table fille son nouveau tablespace et c'est terminé.

Vous m'indiquerez comment vous pouvez rajouter une borne de partitionnement et scinder les lignes en deux espaces de stockage avec une seule commande ALTER TABLE. Je suis curieux de lire votre solution.

Bref, encore un article à charge de la part de SQLpro, rien de bien nouveau sous le soleil.

Visiblement vous ne lisez que les propos négatifs et les articles à décharge que j'écris. Ne seriez vous pas un tantinet partisan ???

Sachez que si je me suis intéressé à ce sujet, c'est parce que j'y ai été confronté pour une solution applicative écrite à l'origine avec PostGreSQL. Il s'agissait d'un système de gestion de données très critique (prévention des catastrophe naturelle) pour une collectivité territoriale. À l'origine le système était sous PG, mais compte tenu de la complexité du partitionnement, des performances médiocre des mises à jours lorsque le critère change et de l'impossibilité d'avoir une haute dispo en temps réel, le choix à basculé sous SQL Server en dépit des préconisations d'utilisation du "free" dans les sphères étatiques.
Aujourd'hui ce système qui gère le plus important réseau hydraulique de France est repris par de nombreuses autres collectivités et intéresse l'étranger. Ce n'est hélas pas avec PG que nous avons pu le concevoir.... (sinon, cela aurait sans doute coûter moins cher en licences, et en impôts !).

A +

Dernière modification par SQLpro (10/10/2011 12:07:24)

SQLpro · 10/10/2011 12:13:08

kenrio a écrit :

Juste pour info pourquoi s'obstiner à comparer mssql et postgresql ?
De mon point de vue, je connais bcp de dba mssql et aucun ne passera sur postgresql.
Donc je trouve ces comparaisons complètement useless, comparer postgresql et oracle à du sens mais mssql....

Ben voyons... Serait-ce interdit ?
D'après vous SQL Server est une grosse merde tout juste bonne à remplacer Acces ???

Il est amusant de constater parfois des propos d'une flagrante incongruité pour ne pas dire plus !

De plus si je compare MS SQL Server et PostGreSQL c'est parce que :
1) je travaille avec ces deux solutions
2) peu de gens font ce travail
3) cela rend services à de nombreux utilisateurs qui connaissent l'un des système et cherchent à savoir comment l'implémenter dans l'autre...

À part cela, voulez-vous que je supprime cet article ?
En quoi cela vous gène t-il ?
Avez vous peur que SQL Server ne supplante PostGreSQL ?

J'en reste pantois... Je croyais le monde libre ouvert... Me fais-je des illusions ???

A +

Dernière modification par SQLpro (10/10/2011 12:13:37)

kenrio · 10/10/2011 12:32:19

SQLpro a écrit :

Ben voyons... Serait-ce interdit ?
D'après vous SQL Server est une grosse merde tout juste bonne à remplacer Acces ???
Il est amusant de constater parfois des propos d'une flagrante incongruité pour ne pas dire plus !

je ne crois pas avoir écris ce genre de choses... ms sql est un très bon outils, et je ne cracherais jamais sur ce produit, je sais pas où vous allez chercher ça dans mes propos...

SQLpro a écrit :

De plus si je compare MS SQL Server et PostGreSQL c'est parce que :
1) je travaille avec ces deux solutions

pas de soucis, mais à mon avis vous utilisez postgres chez vous pour faire mumuse et mssql pour votre travail ( je fais erreur ? )

SQLpro a écrit :

2) peu de gens font ce travail

car comme je l'ai dis quasiment personne venant de microsoft ira chez postrgesql ( cout(inverse), support(lol), windows,... )

SQLpro a écrit :

3) cela rend services à de nombreux utilisateurs qui connaissent l'un des système et cherchent à savoir comment l'implémenter dans l'autre...
À part cela, voulez-vous que je supprime cet article ?
En quoi cela vous gène t-il ?

j'ai jamais rien demandé de la sorte... !

SQLpro a écrit :

Avez vous peur que SQL Server ne supplante PostGreSQL ?

c'est comique cette phrase.
Comment peut on supplanter un produit qui n'a qu'un petit pourcentage d'utilisation comparé aux blockbusters ?

SQLpro a écrit :

J'en reste pantois... Je croyais le monde libre ouvert... Me fais-je des illusions ???
A +

la phrase qui tue j'adore

Pour votre cas d'études que vous citez un peu plus haut, vous êtes en train de dire qu'a cause du partitionnement les clients n'ont pas pris postgres ?

jpargudo · 10/10/2011 16:08:21

Hop,

SQLpro a écrit :

[...]une solution applicative écrite à l'origine avec PostGreSQL. Il s'agissait d'un système de gestion de données très critique (prévention des catastrophe naturelle) pour une collectivité territoriale. À l'origine le système était sous PG, mais compte tenu de la complexité du partitionnement, des performances médiocre des mises à jours lorsque le critère change et de l'impossibilité d'avoir une haute dispo en temps réel, le choix à basculé sous SQL Server en dépit des préconisations d'utilisation du "free" dans les sphères étatiques.
Aujourd'hui ce système qui gère le plus important réseau hydraulique de France est repris par de nombreuses autres collectivités et intéresse l'étranger. Ce n'est hélas pas avec PG que nous avons pu le concevoir.... (sinon, cela aurait sans doute coûter moins cher en licences, et en impôts !).
A +

Si le système était à l'origine sous PostgreSQL et que ça concerne le plus important réseau hydrolique de France, j'imagine que ça doit avoir un rapport très direct avec ce qu'avait fait Paratronic pour la DDE, en particulier à Nimes: http://www.postgresql.fr/temoignages:paratronic. De mémoire, c'était l'application Sigma (?).

Je connais bien ce projet, pour avoir été consulté sur l'état catastrophique de la base PostgreSQL à l'époque...

J'avais pu sauver un peu les meubles, mais des travaux de fond devaient-être fait, de mémoire, encore, Paratronic n'aura peut-être pas eu le temps de les faire. Il me semble qu'il y avait une histoire de rachat d'une boite, etc...

Bref, j'imagine que vous avez du trouver l'application en l'état, avec un vieux PostgreSQL et tout ce qui ne va pas, que vous décrivez ci-dessus... non?

Bien à vous,

gleu · 10/10/2011 19:53:49

C'est ce qui est montré dans l'aide en ligne à ce sujet : http://docs.postgresql.fr/8.2/ddl-partitioning.html

Hmmm, la 8.2, publiée en fin 2006. Vous pourriez utiliser une version plus récente.

De plus passer par des déclencheurs ne réduit pas la complexité, il l'augmente vu qu'au lieu d'une règle il faut deux commandes :
- la création de la fonction trigger
- la création du trigger association la table et son événement et la fonction trigger.

Mais l'ajout d'un trigger permet de remplacer toutes les règles. Donc c'est moindre en nombre de commandes.

Mais c'est bien dommage car l'intérêt majeur du partitionnement c'est le stockage physique !

PostgreSQL propose autant au niveau du stockage. Le seul point qui n'est pas là, c'est les quotas. Qui est plutôt système, et non pas bases de données. Ça ne me dérange pas personnellement.

Il est d'ailleurs curieux de constater que la propagation des contraintes des tables en héritage est tantôt effectives pour certaines, tantôt non effectives pour d'autres.

Les seules contraintes qui ne peuvent pas être héritées sont les contraintes qui dépendent d'un index (donc contrainte unique et clé primaire). C'est logique, ces contraintes sont forcées grâce à un index, or un index ne peut pas être créé sur plusieurs tables.

Il aurait été plus intelligente soit de tout propager, soit de ne rien propager, soit de rajouter une option pour forcer la propagation au coup par coup ou globalement... Encore un point critique

"Plus intelligent", "point critique"... très subjectif.

Certes, mais la complexité du plan textuel parle d'elle même !

Oui, je n'ai pas dit le contraire. Difficile d'en attendre autre chose avec un contournement. Encore une fois, PostgreSQL ne propose pas cette fonctionnalité mais dispose d'un contournement qui permet d'aider ceux qui en auraient besoin.

À moins d'être idiot, je pense que vous vous trompez...

Je ne me trompe pas, je parlais à la création de la table fille. Je ne parlais pas après création. Il est évident qu'après création d'une table héritant d'une autre table, les nouvelles colonnes ne sont pas automatiquements ajoutées comme les nouveaux attributs ne sont pas non plus ajoutées.

Mon article compare les deux solutions (SQL Server vs PostGreSQL) et montre à l'évidence que le coût induit par la complexité de mise en œuvre est très largement en défaveur de PostGreSQL.

Je ne conteste pas que SQL Server fait beaucoup mieux dans ce domaine. Je le dis même à mes clients en formation. Cependant, encore une fois, PostgreSQL ne propose pas cette fonctionnalité. Il propose juste un contournement, ce qui en explique ses limitations. D'où le fait que je ne pense pas qu'il soit fair-play de comparer les deux.

Sauf que vous ne m'avez toujours pas montré d'exemple !

La réponse que je me suis pris ne m'a donné aucune envie d'aller plus loin.

Peut être pouvez-vous vous en occuper chez Dalibo.

Je ne crois pas aux benchmarks sur des bases de tests. Je ne perdrais donc pas de temps à faire ça.

Vous m'indiquerez comment vous pouvez rajouter une borne de partitionnement et scinder les lignes en deux espaces de stockage avec une seule commande ALTER TABLE. Je suis curieux de lire votre solution.

Je ne parlais pas de borne de partitionnement, mais de tablespace.

Visiblement vous ne lisez que les propos négatifs et les articles à décharge que j'écris. Ne seriez vous pas un tantinet partisan ???

Il est évident que je suis partisan de PostgreSQL. Ça ne veut pas dire pour autant que je ne suis pas objectif. J'avoue que je vois beaucoup de propos négatif dans ce que vous dites et que, évidemment, ça m'énerve beaucoup. Participer à un forum PostgreSQL et le critiquer en permanence pour couronner SQL Server comme seul SGBD intéressant, c'est limite et il ne faut pas vous étonner à récupérer des critiques.

SQLpro · 11/10/2011 00:48:20

De plus passer par des déclencheurs ne réduit pas la complexité, il l'augmente vu qu'au lieu d'une règle il faut deux commandes :
- la création de la fonction trigger
- la création du trigger association la table et son événement et la fonction trigger.

Mais l'ajout d'un trigger permet de remplacer toutes les règles. Donc c'est moindre en nombre de commandes.

reste que le nombre de commande SQL est toujours le même, donc aucun gain !

Mais c'est bien dommage car l'intérêt majeur du partitionnement c'est le stockage physique !

PostgreSQL propose autant au niveau du stockage. Le seul point qui n'est pas là, c'est les quotas. Qui est plutôt système, et non pas bases de données. Ça ne me dérange pas personnellement.

Vous ne maîtrisez visiblement pas le sujet... Rien à voir avec les quota. le quota c'est informer le système qu'un fichier va croitre de n et donc demander au système de prévoir l'espace pour l'expansion du fichier, qui s'il croit va être fragmenté. La gestion des espaces de stockage des bases de données, c'est de créer un fichier NON FRAGMENTÉ d'un volume donné par exemple 80 Go, avec des granules choisit pour être situées aux endroit des disques les plus rapide d'accès pour optimiser les accès disques. Lisez par exemple le cours de Rigaux du cnam pour comprendre cette chose là, aux moins vous aurez appris quelque chose que les SGBDR comme Oracle, DB2 ou SQL Server savent faire depuis plus de 15 ans !

Il est d'ailleurs curieux de constater que la propagation des contraintes des tables en héritage est tantôt effectives pour certaines, tantôt non effectives pour d'autres.

Les seules contraintes qui ne peuvent pas être héritées sont les contraintes qui dépendent d'un index (donc contrainte unique et clé primaire). C'est logique, ces contraintes sont forcées grâce à un index, or un index ne peut pas être créé sur plusieurs tables.

Et pourquoi ce choix, car c'est un choix de conception tordu de PostGreSQL... ! En matière d'héritage la norme indique que l'héritage doit se faire sur toutes les contraintes... Il n'y a aucune logique la dedans, si ce n'est l'incapacité de PG a faire des choses claires !

À moins d'être idiot, je pense que vous vous trompez...

Je ne me trompe pas, je parlais à la création de la table fille. Je ne parlais pas après création. Il est évident qu'après création d'une table héritant d'une autre table, les nouvelles colonnes ne sont pas automatiquements ajoutées comme les nouveaux attributs ne sont pas non plus ajoutées.

La encore je ne vous comprend pas. Une nouvelle colonne ajoutée à la table mère par ALTER TABLE de la table mère est bien propagée, dans les tables fille. Je crois que ous vous embrouiller pour ne pas reconnaître que sur ce coup vous avez tort !

Mon article compare les deux solutions (SQL Server vs PostGreSQL) et montre à l'évidence que le coût induit par la complexité de mise en œuvre est très largement en défaveur de PostGreSQL.

Je ne conteste pas que SQL Server fait beaucoup mieux dans ce domaine. Je le dis même à mes clients en formation. Cependant, encore une fois, PostgreSQL ne propose pas cette fonctionnalité. Il propose juste un contournement, ce qui en explique ses limitations. D'où le fait que je ne pense pas qu'il soit fair-play de comparer les deux.

Soyez adulte, il n'y a pas de fair play à avoir dans le domaine de l'entreprise, de l’industrie ou de l'économie. Il y a des choses qui marchent bien, d'autres moins bien, et d'autres pas du tout. Il s'agit d'être informé pour choisir. A l'évidence vous confondez marketing, coup de cœur et réalités techniques.

Peut être pouvez-vous vous en occuper chez Dalibo.

Je ne crois pas aux benchmarks sur des bases de tests. Je ne perdrais donc pas de temps à faire ça.

Teins, là quand ça vous arrange vous vous défilez... Amusant !

Vous m'indiquerez comment vous pouvez rajouter une borne de partitionnement et scinder les lignes en deux espaces de stockage avec une seule commande ALTER TABLE. Je suis curieux de lire votre solution.

Je ne parlais pas de borne de partitionnement, mais de tablespace.

L'un étant intimement lié à l'autre, vous prenez encore une fois ce qui vous arrange pour vous défiler !

Visiblement vous ne lisez que les propos négatifs et les articles à décharge que j'écris. Ne seriez vous pas un tantinet partisan ???

Il est évident que je suis partisan de PostgreSQL. Ça ne veut pas dire pour autant que je ne suis pas objectif. J'avoue que je vois beaucoup de propos négatif dans ce que vous dites et que, évidemment, ça m'énerve beaucoup. Participer à un forum PostgreSQL et le critiquer en permanence pour couronner SQL Server comme seul SGBD intéressant, c'est limite et il ne faut pas vous étonner à récupérer des critiques.

Moi j'essaye modestement d'être objectif et de parler de ce que je constate. Malheureusement mes journées, n'ayant comme tout le monde que 24 h, je ne peut pas consacrer autant de temps que je le voudrais à tout constater sur tout et je me limite donc volontairement à mon domaine de connaissance afin d'éviter d'affirmer n'importe quoi, comme je le vois trop souvent sur des blog de benêts. Je constate d'ailleurs qu'aucun des propos tenu dans cet article n'a été invalidé par une preuve de code un tant soit peu sérieuses, ce qui fait qu’involontairement vous confirmez tout mes dires, et par là même je vous en remercie !

A +

Dernière modification par SQLpro (11/10/2011 00:50:15)

gleu · 11/10/2011 07:09:42

reste que le nombre de commande SQL est toujours le même, donc aucun gain !

Je viens de dire qu'il y a moins de commandes à exécuter car vous n'avez pas toutes les règles à créer. Vous ne créez qu'un trigger et sa fonction, au lieu de 3x le nombre de partitions avec des règles. Même avec une seule partition, on est gagnant. Et c'est beaucoup plus simple à débugguer que des règles.

Vous ne maîtrisez visiblement pas le sujet...

Gardez-vous ce genre de commentaires. Vous vous étonné après que vous n'êtes pas bien accueilli.

J'ai bien compris ce point là, qui n'empêche en rien la fragmentation à l'intérieur du fichier créé.

... choix de conception tordu ...

Encore un commentaire technique à ce que je vois...

... Il n'y a aucune logique la dedans, si ce n'est l'incapacité de PG a faire des choses claires ! ...

Là-aussi, c'est technique

Une nouvelle colonne ajoutée à la table mère par ALTER TABLE de la table mère est bien propagée, dans les tables fille.

Après tests, en effet, je me suis trompé sur ce point.

scheu.postgresql · 17/10/2011 11:54:48

Je suis effaré devant tant de commentaires pour dénigrer SQL Pro (que je ne connais pas personnellement) alors que son article est tout-à-fait objectif.

Ce forum ressemble à une secte Pro-Postgresql extrêmiste qui n'accepte pas les critiques ni les comparaisons, et dont les avis sont tout sauf objectifs
A la limite je vous dis merci de ne pas censurer les messages de ceux qui ne pensent pas comme vous car on n'en est pas loin

Mr Argudo, Mr Lelarge et d'autres, vous êtes tout-à-fait louables de participer activement à Postgresql (produit que j'apprécie je précise) de manière bénévole et communautaire, mais aussi via votre société Dalibo qui fait apparemment des prestations. De ce point de vue, on ne peut pas dire que votre avis soit forcément plus objectif que celui de SQL pro, bien que je peux comprendre que ce soit dans votre intérêt de vanter les mérites de Postgresql
Mais quand ça tourne au dénigrement de tous ceux qui osent émettre des critiques sur Postgresql, je n'accepte pas.

Je ne connais pas l'historique du conflit "historique" vous opposant apparemment, je me contenterai donc juste d'intervenir concernant l'article de SQL Pro sur le partitionnement

L'article de SQL Pro sur le partitionnement est tout-à-fait objectif et ses arguments sont fondés, pour l'avoir testé moi-même dans mon entreprise je peux vous confirmer que jamais je ne conseillerai d'utiliser le partitionnement sous Postgresql dans les versions actuelles.
J'ai d'ailleurs émis mon point de vue, je vous invite à participer au débat sur developpez.com si vous souhaitez défendre vos arguments :
http://www.developpez.net/forums/d11401 … ql-server/

Franchement à voir comment vous dénigrez les arguments de SQL Pro, quelqu'un qui passe sur ce forum sans connaitre le partitionnement en arriverait presque à croire que c'est aussi bien fait sous Postgresql que sous Oracle ou SQL Server, alors que c'est loin d'être le cas

Salutations

scheu.postgresql · 17/10/2011 11:56:37

Au pire, je remets mes commentaires sur ce forum si vous souhaitez en débattre ici

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

daamien · 17/10/2011 12:52:25

@scheu.postgresql

Merci de ne pas copier coller ici des messages issus de developpez.net . Je suis persuadé que les visiteurs de postgresql.fr sont capables d'aller sur le forum Developpez et sur d'autres si cela les intéressent.

Pour répondre à votre dernier message : il me semble que vous dites des choses de manière bien péremptoire alors que :

a/ vous admettez n'a avoir pas fait beaucoup de tests
b/ vous parler d'une version sortie en 2006 et qui sera obsolète dans les semaines qui viennent.

ça me laisse dubitatif....

Ce genre de commentaires "objectifs" est peut-être courant sur developpez.com mais ici vous aurez du mal être pris au sérieux :-)

scheu.postgresql · 17/10/2011 14:30:18

Je suis d'accord avec SQLpro sur tout son article

Le peu de tests que j'ai fait m'a suffi pour voir les lacunes de Postgresql sur le partitionnement. Quand on voit que, sur un cas simple, à la première requête un peu complexe l'optimiseur Postgresql perd les pédales et n'est même pas capable de ne lire que la bonne partition, pas besoin d'aller beaucoup plus loin dans l'analyse ...

J'ai testé en version 8.2, depuis aucune note de version des nouvelles versions n'indique une amélioration concernant le partitionnement. A contrario, vous n'avez pas admis que je me trompais sur mes commentaires.
Quand SQL Pro dit que le partitionnement est complexe avec les règles, triggers, etc ... et que votre argument c'est "vous n'avez pas testé la dernière version", ça me fait rire car la doc a l'air similaire et rien d'indique qu'il y a eu réellement un changement ou une amélioration de ce côté

A contrario, vous avez l'air de très mal connaître les possibilités d'Oracle ou SQL Server, dans ce cas je peux comprendre que ça vous dépasse d'admettre que Postgresql puisse avoir des lacunes.

J'aurais espéré de la part de Dalibo et des membres de la communauté Postgresql une réponse un peu plus honnête du genre "oui effectivement Postgresql a encore du retard sur ce point, c'est encore compliqué à utiliser et peu performant, mais dans une prochaine version ça va être amélioré", ça aurait été plus objectif.

Là je ne suis pas sûr que ça renforce votre crédibilité, dommage

Je précise, je ne travaille ni chez Oracle, ni chez SQL Server, je n'ai aucun intérêt commercial, je ne connais pas personnellement SQL Pro, je suis juste un DBA dont l'entreprise a une expérience Oracle et Postgresql depuis plusieurs années.
De ce fait j'ai comme tout le monde le droit de faire part de mon retour d'expérience. Ca serait d'ailleurs intéressant si d'autres DBA du monde de l'entreprise pouvaient nous faire part de leur expérience

Salutations

rjuju · 17/10/2011 14:39:37

gleu a écrit :

Par contre, je suis bien d'accord que le partitionnement dans PostgreSQL n'existe pas. Il existe un moyen de contourner ce manque et il faut en connaître les avantages et les inconvénients. Ce n'est qu'un contournement.

Doc officielle PostGreSQL a écrit :

PostgreSQL™ offre un support basique du partitionnement de table.

Je trouve ça tout à fait honnête, crédible et objectif.

Marc Cousin · 17/10/2011 15:12:56

Juste pour ne pas laisser traîner une affirmation fausse sur ce forum.

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

et

J'ai testé en version 8.2, depuis aucune note de version des nouvelles versions n'indique une amélioration concernant le partitionnement. A contrario, vous n'avez pas admis que je me trompais sur mes commentaires.

Ça ira plus vite de le prouver non ?

marc=# \d+ parent_test 
               Table "public.parent_test"
  Column  |  Type   | Modifiers | Storage | Description 
----------+---------+-----------+---------+-------------
 a        | integer |           | plain   | 
 col_date | date    |           | plain   | 
Child tables: fils_test1,
              fils_test2

marc=# \d fils_test1
   Table "public.fils_test1"
  Column  |  Type   | Modifiers 
----------+---------+-----------
 a        | integer | 
 col_date | date    | 
Check constraints:
    "fils_test1_col_date_check" CHECK (col_date < '2011-01-01'::date)
Inherits: parent_test


marc=# \d fils_test2
   Table "public.fils_test2"
  Column  |  Type   | Modifiers 
----------+---------+-----------
 a        | integer | 
 col_date | date    | 
Check constraints:
    "fils_test2_col_date_check" CHECK (col_date >= '2011-01-01'::date AND col_date < '2012-01-01'::date)
Inherits: parent_test

marc=# \d foreign_table 
Table "public.foreign_table"
  Column  | Type | Modifiers 
----------+------+-----------
 col_date | date | 


marc=# EXPLAIN SELECT * from parent_test join foreign_table using (col_date) where foreign_table.col_date= '2011-01-01';
                                     QUERY PLAN                                     
------------------------------------------------------------------------------------
 Nested Loop  (cost=0.00..78.58 rows=144 width=8)
   ->  Append  (cost=0.00..36.75 rows=12 width=8)
         ->  Seq Scan on parent_test  (cost=0.00..0.00 rows=1 width=8)
               Filter: (col_date = '2011-01-01'::date)
         ->  Seq Scan on fils_test2 parent_test  (cost=0.00..36.75 rows=11 width=8)
               Filter: (col_date = '2011-01-01'::date)
   ->  Materialize  (cost=0.00..40.06 rows=12 width=4)
         ->  Seq Scan on foreign_table  (cost=0.00..40.00 rows=12 width=4)
               Filter: (col_date = '2011-01-01'::date)
(9 rows)

Pas de parcours de fils_test1 … par contre ça ne marche que pour les égalités. Si ça avait été foreign_table.col_date> '2011-01-01', PostgreSQL aurait effectivement échoué. Il ne gère la transitivité que pour l'opérateur «=». Et il y a toujours le parcours de la table parente (vide…)

scheu.postgresql · 17/10/2011 15:16:41

rjuju a écrit :

gleu a écrit :
Par contre, je suis bien d'accord que le partitionnement dans PostgreSQL n'existe pas. Il existe un moyen de contourner ce manque et il faut en connaître les avantages et les inconvénients. Ce n'est qu'un contournement.
Je trouve ça tout à fait honnête, crédible et objectif.

Mouais enfin au premier abord SQL Pro s'est fait incendier, pour finalement que gleu avoue à demi-mots qu'il a raison sur le fond. C'est au moins une bonne chose qu'il l'ai reconnu, mais au final si personne ne soulève les limitations du partitionnement sous Postgresql, on a l'impression en lisant la doc que c'est génial, alors que cça fait un peu publicité mensongère
Car au final quand on creuse, on se rend compte que ce n'est pas sérieux, et là on entend "oui mais au pire en faisant comme ceci pour faire telle rustine ça peut être faisable pour certains cas" ... Mouais ...

Quand une entreprise choisit un produit pour répondre à un besoin pour une appli critique, volumineuse, complexe, elle préfère payer pour un produit qui répondra aux besoins plutôt que de croire naïvement qu'elle va faire des économies en prenant un produit open-source, et au final avoir des ennuis derrière car, une fois le vernis gratté, on se rend compte des manquements ...
En entreprise on veut un produit qui marche quand on l'installe, pas un produit sur lequel il faut installer soi-même les rustines

scheu.postgresql · 17/10/2011 15:20:05

Marc Cousin a écrit :

par contre ça ne marche que pour les égalités. Si ça avait été foreign_table.col_date> '2011-01-01', PostgreSQL aurait effectivement échoué

Ca me paraît bien insuffisant pour pouvoir migrer un décisionnel sous Postgresql, quand on a des utilisateurs qui font des requêtes ad-hoc via des outils de reporting

Sur un datawarehouse la majorité des requêtes se font sur une période avec un "between", donc dans ce cas Postgresql ne sait pas gérer le partitionnement si j'ai bien compris ?

Marc Cousin · 17/10/2011 15:22:45

Personne ne vous a demandé de migrer votre décisionnel. Je signale juste que vous avez écrit quelque chose de faux. Votre décisionnel ne m'intéresse pas.

scheu.postgresql · 17/10/2011 15:29:15

Marc Cousin a écrit :

Personne ne vous a demandé de migrer votre décisionnel. Je signale juste que vous avez écrit quelque chose de faux. Votre décisionnel ne m'intéresse pas.

J'aurais simplement aimé qu'on reconnaisse que Postgresql ne peut par encore, aujourd'hui, remplacer Oracle ou SQL Server pour une application complexe, volumineuse et critique en entreprise

Ce qui me gêne dans la démarche de certains membres c'est qu'à chaque problème que quelqu'un soulève concernant un manquement de Postgresql, on lui répond "on peut s'en sortir en faisant comme cela ou en mettant telle rustine", ce qui laisse sous-entendre qu'on pourrait tout résoudre avec Postgresql.
En gros on lit la doc Postgresql sur le partitionnement et on a l'impression qu'on peut faire tourner un datawarehouse de 500 Go ...

Jamais ou très rarement on va lire "non Postgresql ne fait pas encore cela comparé à Oracle ou SQL Server"

Cette démarche ne me semble donc pas toujours honnête

Merci néanmoins de m'avoir répondu

Dernière modification par scheu.postgresql (17/10/2011 15:34:39)

daamien · 17/10/2011 16:25:41

scheu.postgresql a écrit :

J'aurais simplement aimé qu'on reconnaisse que Postgresql ne peut par encore, aujourd'hui, remplacer Oracle ou SQL Server pour une application complexe, volumineuse et critique en entreprise

Très honnêtement je trouve vos affirmations péremptoires et un peu abstraites. Des bases Oracle et SQL Server sont migrées vers PostgreSQL quotidiennement. L'inverse n'est pas vrai. Ces bases sont utilisées dans la grandes distributions, dans le secteur public, les médias... La réalité vous donne tort

Par ailleurs, vous donnez des leçons d’honnêteté alors même que vous assénez des "vérités" sans apporter de faits et sans répondre à vos contradicteurs.

Encore une fois, ce genre d'affirmations polémiques et moralisantes marchent peut-être sur developpez.com mais ici ça fait flop :-)

kenrio · 17/10/2011 17:04:35

scheu.postgresql a écrit :

J'aurais simplement aimé qu'on reconnaisse que Postgresql ne peut par encore, aujourd'hui, remplacer Oracle ou SQL Server pour une application complexe, volumineuse et critique en entreprise

quand je lis ça j'ai vraiment l'impression que les devs de postgres devraient s'excuser de faire un produit libre qui n'a pas la performance d'un produit qui coûte une fortune...

scheu.postgresql · 17/10/2011 17:34:31

kenrio a écrit :

scheu.postgresql a écrit :
J'aurais simplement aimé qu'on reconnaisse que Postgresql ne peut par encore, aujourd'hui, remplacer Oracle ou SQL Server pour une application complexe, volumineuse et critique en entreprise
quand je lis ça j'ai vraiment l'impression que les devs de postgres devraient s'excuser de faire un produit libre qui n'a pas la performance d'un produit qui coûte une fortune...

Pas s'excuser non, juste être un peu plus explicites et précis concernant les fonctionnalités de Postgresql qu'ils avancent et leurs limitations

Dernière modification par scheu.postgresql (17/10/2011 17:40:16)

scheu.postgresql · 17/10/2011 17:36:52

daamien a écrit :

Des bases Oracle et SQL Server sont migrées vers PostgreSQL quotidiennement. L'inverse n'est pas vrai. Ces bases sont utilisées dans la grandes distributions, dans le secteur public, les médias..

Je n'ai jamais dit que Postgresql ne poyvait pas convenir en entreprise bien au contraire
Pouvez-vous nous en dire plus sur la volumétrie, la complexité des requêtes, le nombre d'utilisateurs simultanés, etc ... des bases que vous migrez en Postgresql, et des éventuels problèmes remontés par vos clients ?

daamien a écrit :

Encore une fois, ce genre d'affirmations polémiques et moralisantes marchent peut-être sur developpez.com mais ici ça fait flop :-)

Je suis d'accord avec vous, sur developpez.com les gens sont pour la plupart des DBA sans parti pris ni intérêt commercial qui donnent leur point de vue objectivement sans dénigrer ou lyncher, alors qu'ici malheureusement ça n'a pas l'air d'être le cas, dommage ...

Dernière modification par scheu.postgresql (17/10/2011 17:38:31)

gleu · 17/10/2011 17:59:55

Comme ça tourne aux insultes de tout côté, qu'à priori les deux côtés ne vont pas pouvoir se réconcilier, je ferme le thread. Ceux qui veulent s'insulter le font ailleurs. Merci.

#1 10/10/2011 02:34:31

Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#2 10/10/2011 09:03:14

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#3 10/10/2011 10:41:50

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#4 10/10/2011 12:05:12

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#5 10/10/2011 12:13:08

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#6 10/10/2011 12:32:19

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#7 10/10/2011 16:08:21

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#8 10/10/2011 19:53:49

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#9 11/10/2011 00:48:20

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#10 11/10/2011 07:09:42

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#11 17/10/2011 11:54:48

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#12 17/10/2011 11:56:37

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#13 17/10/2011 12:52:25

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#14 17/10/2011 14:30:18

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#15 17/10/2011 14:39:37

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#16 17/10/2011 15:12:56

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#17 17/10/2011 15:16:41

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#18 17/10/2011 15:20:05

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#19 17/10/2011 15:22:45

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#20 17/10/2011 15:29:15

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#21 17/10/2011 16:25:41

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#22 17/10/2011 17:04:35

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#23 17/10/2011 17:34:31

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#24 17/10/2011 17:36:52

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

#25 17/10/2011 17:59:55

Re : Article: comparaison solutions partitionnement PostGreSQL / SQL Server

Pied de page des forums

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux