Nouvel article : Migration Oracle ou SQL Server vers PosteGreSQL - les écueils

[SQLpro]

Envoyé par Arnaud B.

J'ai vu les messages d'insulte sur le forum posgresql.fr et j'avoue que j'ai été très déçu de la pauvreté des arguments des détracteurs de l'article (pour ainsi dire, il n'y avait aucun argument). J'attendais mieux de la part d'experts PG...

Notez que j'avais prévu le coup en précisant à la fin de mon article :
Je sais qu'en rédigeant un tel article je vais m'attirer les foudres de nombreux internautes. Je m'y attend et reste serein. J'ai des arguments et une expérience acquise depuis plus de 20 ans par mon travail avec de nombreux SGBDR...
Mais je sais hélas que, chez certains, la passion du libre l'emporte souvent contre la raison du technique !
Bref, ce qui devait arriver, arriva, et je suis habitué à l'intolérance des tenants du libre...

Comme me le disait un spécialiste du libre, lorsque tu prône le libre, tu fait de la charité et c'est noble. Lorsque tu parle du propriétaire, c'est de la pub, c'est mal.

Là ou cela les choque c'est quand on ose comparer le merveilleux PostGreSQL au démoniaque Oracle ou au au suppôt de Satan qu'est Microsoft...

Mais plus on polémique, et plus ça fait du buzz autour de l'article... Donc, je suis preneur !!! ;-)

A +

[frost242]

Envoyé par Arnaud B.

Je reviens sur la reconstruction d'index à chaud (sans verrouiller la table) : c'est étonnant qu'il n'y ait pas une commande qui fasse cette opération automatiquement.

Il me semble que la plupart des SGBDR le proposent non ?

P'tite question de non-expert SGBD : pourquoi ne pas mettre le CREATE INDEX dans la transaction tant qu'à faire ?

Il n'y a pas de commande car certains problèmes d'implémentation se posent. Ce n'est pas insurmontable, mais il faut que quelqu'un de suffisamment compétent se penche dessus. Personnellement je ne le suis pas.

Quant à l'inclusion de la création d'index dans la transaction, c'est tout simplement car on ne peut pas le faire.
Extrait de la doc:

Another difference is that a regular CREATE INDEX command can be performed within a transaction block, but CREATE INDEX CONCURRENTLY cannot.

[estofilo]

Envoyé par SQLpro

Mais plus on polémique, et plus ça fait du buzz autour de l'article... Donc, je suis preneur !!! ;-)

On a remarqué, oui.
Pour ma part, c'est le plus Troll le plus hideux que j'ai lu depuis trois ans que je participe au forum PostgreSQL sur dvp.
Il est clair pour moi que ce genre de provocation est totalement délibérée et sert des intérêts partisans et non l'entraide entre utilisateurs.
C'est une stratégie connue consistant à semer doute-incertitute-peur sur les concurrents, la cerise sur le gâteau étant de se proclamer victime quand on se fait chahuter suite aux provocations.

[frost242]

Envoyé par SQLpro

Notez que j'avais prévu le coup en précisant à la fin de mon article :
Je sais qu'en rédigeant un tel article je vais m'attirer les foudres de nombreux internautes. Je m'y attend et reste serein. J'ai des arguments et une expérience acquise depuis plus de 20 ans par mon travail avec de nombreux SGBDR...
Mais je sais hélas que, chez certains, la passion du libre l'emporte souvent contre la raison du technique !
Bref, ce qui devait arriver, arriva, et je suis habitué à l'intolérance des tenants du libre...

Comme me le disait un spécialiste du libre, lorsque tu prône le libre, tu fait de la charité et c'est noble. Lorsque tu parle du propriétaire, c'est de la pub, c'est mal.

Là ou cela les choque c'est quand on ose comparer le merveilleux PostGreSQL au démoniaque Oracle ou au au suppôt de Satan qu'est Microsoft...

Pour ma part, ce que je trouve dérangeant dans cet article, c'est qu'il appuie sur différents points qui peuvent faire mal mais qui peuvent aussi faire penser que SQLPro ne connaît pas du tout PostgreSQL.
Et sans compter le fait qu'il ne fait pas dans la demi-mesure.

Je m'explique:

Point 2/ Une gestion des transactions "curieuse".
SQLPro déplore l'absence de sous-transactions. Je n'ai pas d'expérience de cette fonctionnalité sur un autre SGBD.
Néanmoins, dans PostgreSQL vous pouvez gérer ce genre de problématique avec des SAVEPOINT. Il n'est donc pas possible d'utiliser le couple BEGIN/COMMIT|ROLLBACK dans une transaction déjà ouverte, mais vous pouvez remplacer un BEGIN par un SAVEPOINT, le COMMIT par un RELEASE SAVEPOINT et le ROLLBACK par un ROLLBACK TO SAVEPOINT.

En gros:

Code :

1
2
3
4
5
6
7
8
 
BEGIN;
... du SQL ...
SAVEPOINT monsavepoint;
... encore du SQL ...
RELEASE SAVEPOINT monsavepoint;
... ON termine avec du SQL ...
COMMIT;

J'ai utilisé cette construction dans des fonctions et ça fonctionne très bien.

Il me semble que le sujet avait été évoqué ailleurs ou ici, donc je n'étais pas revenu dessus. J'aimerai bien que l'on puisse développer ce point.

Point 4/ Pas de hint pour forcer un plan d'exécution
Là, ce qui me brûle les yeux c'est l'exemple choisi. Je l'ai déjà évoqué mais je reviens dessus.
Il est connu et reconnu que Postgres ne sait pas utiliser un index pour lire des données. Lorsqu'il fait une lecture par un index, il doit forcément lire les blocs de données associés pour déterminer si la ligne est visible ou non par la transaction courante (pour plus de détails sur ce mécanisme, je vous renvoie vers ce livre dont j'ai contribué à la traduction.
Donc tout ça parce que les index ne portent pas les informations de visibilité des données.
La fonctionnalité arrive en 9.2 normalement, cf un lien que j'ai donné précédemment.

Point 6/ Une indexation à la traîne.
La vue pg_stat_all_indexes (et non pg_stat_sys_indexes !!! qui ne montrent que les index systèmes) permet de déterminer si un index est inutile.

Point 8/ Une administration coûteuse.
A mon avis, la partie sur VACUUM gagnerait à être revue à la suite des commentaires qui ont été exprimés ici.

En dehors de ça, il existe des outils externes au SGBD qui permettent de palier plus ou moins à certains manques énoncés. Je les ai cité en privé à SQLPro et ils sont indiqués en références (voir modules externes compensatoires).
Parmi ces outils, on a pg_stat_statements (et aussi auto_explain qui a été cité ici). Ce ne sont pas des outils intégrés au SGBD, mais qui font partie de la distribution de Postgres. C'est la philosophie du SGBD de vous proposer des modules externes pour étendre le SGBD, mais j'imagine que SQLPro ne les a pas cités car ils ne font pas partie de la distribution de base. De mon côté, j'aimerai vraiment qu'ils soient intégrés au moteur.
Je citerai aussi pg_statsinfo qui est un équivalent plus ou moins riche à AWR d'Oracle. Dommage que la licence soit ambiguë (licence NTT OSS) et qu'il ne soit pas non plus intégré directement au moteur.
Ces modules externes sont à la fois une force pour Postgres car ils permettent d'étendre le SGBD de manière assez fantastique. Mais c'est aussi une faiblesse car un certain nombre d'outils indispensables pour un DBA ne sont pas intégrés.

Point 9/ Pas de pooling.
On en revient au débat sur les modules externes.
Je citerai également PGBouncer qui est plus léger que PGPool - en fait qui n'adresse pas tout à fait la même problématique.

Vu l'existence de ces outils, pour moi le titre aurait dû être "pas de pooling intégré". Dans certaines structures, la nécessité d'utiliser des outils externes est un réel problème alors que ça peut sembler tout naturel ailleurs. Je travaille dans le premier type de structure, où l'on se prive d'un certain nombre de choses à cause de cela, et notamment du pooling. C'est difficile de faire évoluer les choses dans un gros mammouth.

Point 10/ Pas de vision des plans d'exécution en cours.
C'est vrai et faux. Comme SQLPro ne fait pas dans le consensus, c'est faux
Là encore, il faut faire appel à un module à ajouter explicitement à la base pour avoir un début de réponse. Cf auto_explain.

Point 11/ Un système de sauvegarde peu performant.
Encore un point à développé.

J'ai été surpris d'une question de SQLPro sur ce fil, demandant si un backup à chaud est réalisé par magie ou parce qu'un gros verrou est posé sur la base. Du coup, je doute qu'il ait une bonne vision de ce qu'il est possible de faire.
J'imagine également qu'il compare PostgreSQL à SQL Server où il existe un outil intégré. Dans PostgreSQL, on en est encore à l'époque du ALTER SYSTEM BEGIN BACKUP/END BACKUP d'Oracle. Voir les échanges précédents.

Il existe depuis la 9.1 un outil intégré appelé pg_basebackup. Pour l'instant il est assez basique, mais devrait évoluer par la suite (on parle de compression...). Pour avoir un aperçu de ses possibilités, je vous recommande cet article. N'étant pas encore passé à la 9.1, je ne peux pas en dire beaucoup plus. J'ai un doute sur la viabilité des backups si la base subit une forte charge et que le paramètre wal_keep_segments n'est pas suffisamment élevé (voir doc de l'outil, paramètre -x).

Point 12/ Pas de chiffrement.
Il est possible de faire du chiffrement avec le module contrib pgcrypto, cité en référence. Merci de l'avoir ajouté.


Et pour conclure avec ma propre expérience: à la vue d'un certain nombre d'applications qui utilisent de l'Oracle dans mon organisation, c'est aberrant de ne pas remplacer cet Oracle par du PostgreSQL ! Et ça, sans prendre le moindre risque...

Ceci dit, le fait que "CREATE INDEX ... DROP EXISTING" existe sur SQL Server depuis 1998: je m'en contrefous !

[Arnaud B.]

Certes l'article ne fait pas dans la demi-mesure. Et alors ?
C'est un point de vue. Et un point de vue argumenté. Ce qui ne veut pas dire que les arguments sont vrais, mais au moins on peut aller vérifier, poser des questions, ou même, sans être expert, se faire une opinion sur la plausibilité de l'argumentation si ça a l'air de tenir la route.

Après, je ne suis pas expert SGBDR, et peut être que je me fais ballader par des arguments faussement plausibles.

Mais ce qui est sûr, c'est que quelqu'un qui affirme des choses du genre "c'est un gros troll hideux" "son auteur est un provocateur qui ne connait pas pg" etc... (je résume certains posts vu ici et sur pg.fr) : hé bien, ça ne me donne pas du tout envie de les croire sur parole !

Peut être n'ont ils pas l'envie ni le temps de développer leurs arguments ? Dans ce cas qu'ils le disent, qu'ils renvoient à un lien, qu'ils donnent au moins un contre-exemple... ou qu'ils ne disent rien.

Mais leurs réponses non-argumentées (pour la plupart. Je ne vise pas ici ceux qui comme frost242 s'efforcent de débattre de manière objective) renforcent de mon point de vue la crédibilité de SqlPro.

Cdlt, Arnaud.

Envoyé par frost242

Pour ma part, ce que je trouve dérangeant dans cet article, c'est qu'il appuie sur différents points qui peuvent faire mal mais qui peuvent aussi faire penser que SQLPro ne connaît pas du tout PostgreSQL.
Et sans compter le fait qu'il ne fait pas dans la demi-mesure.

[Arnaud B.]

Pour appuyer ton argument, j'ajouterai que nous répondons régulièrement à des marchés publics pour des progiciels, dans lesquels il est demandé une utilisation d'Oracle, alors que les BDD gérées ne dépasseront jamais quelques Go et que les accès sont faiblement concurrentiels sur 20 utilisateurs max.

Il me semble que les administrations et collectivités locales auraient mieux à faire de notre argent que de le mettre dans des licences Oracle pour de telles applis.

Cdlt, Arnaud.

Envoyé par frost242

Et pour conclure avec ma propre expérience: à la vue d'un certain nombre d'applications qui utilisent de l'Oracle dans mon organisation, c'est aberrant de ne pas remplacer cet Oracle par du PostgreSQL ! Et ça, sans prendre le moindre risque...

[frost242]

Envoyé par Arnaud B.

Il me semble que les administrations et collectivités locales auraient mieux à faire de notre argent que de le mettre dans des licences Oracle pour de telles applis.

Pour travailler de l'autre côté, justement dans une administration, je ne peux que t'appuyer !

[CinePhil]

SQLPro savait qu'il allait déclencher une polémique en écrivant son article et c'était d'ailleurs l'un des buts recherchés je pense !

Envoyé par SQLPro

Mais plus on polémique, et plus ça fait du buzz autour de l'article... Donc, je suis preneur !!! ;-)

Cependant, je ne considère pas cette discussion comme un troll, encore moins hiideux (estofilo, tu me déçois ! ) mais comme un débat intéressant, même si la plupart des notions qui y sont abordées me dépassent, au regard de mon niveau de compétence actuel en SGBD.

En caricaturant à peine, SQLPro est un extrémiste des bases de données ! Son expérience et les problématiques professionnelles auxquelles il est confronté l'amènent à penser naturellement "grosses BDD sensibles avec de nombreux utilisateurs", alors que la plupart des lecteurs de ses contributions sur DVP (et peut-être encore plus sur le forum de Postgresql.fr à ce que j'ai pu lire) sont plutôt des utilisateurs de "petites" bases de données. Ces derniers sont généralement satisfaits d'utiliser MySQL ou Postgresql et ont le sang qui meur monte à la tête, certes un peu vite, quand ils voient des critiques, parfois acerbes voire exprimées radicalement, sur leur SGBD favori.

Envoyé par frost242

C'est la philosophie du SGBD de vous proposer des modules externes pour étendre le SGBD
...
Ces modules externes sont à la fois une force pour Postgres car ils permettent d'étendre le SGBD de manière assez fantastique. Mais c'est aussi une faiblesse car un certain nombre d'outils indispensables pour un DBA ne sont pas intégrés.

Cette discussion parmi d'autres en général et l'extrait ci-dessus en particulier m'inclinent à penser que MySQL ou Postgresql sont largement suffisants pour des besoins relativement simples et des BDD pas trop volumineuses ne nécessitant pas de paramétrages complexes ni d'administration lourde.
En intermédiaire, on peut ajouter des outils supplémentaires au SGBD pour faire des choses plus pointues et, à partir d'un certain seuil qui reste peut-être à déterminer au cas par cas, il faut passer à la grosse artillerie à licence payante de chez Microsoft, Oracle ou autre.

Frédéric, vu ta grande expérience, ce qui serait peut-être plus constructif, c'est d'écrire un article qui donnerait des clés pour déterminer à partir de quel niveau de complexité il est recommandé de passer à un SGBD propriétaire.

A+

[SQLpro]

Envoyé par CinePhil

Frédéric, vu ta grande expérience, ce qui serait peut-être plus constructif, c'est d'écrire un article qui donnerait des clés pour déterminer à partir de quel niveau de complexité il est recommandé de passer à un SGBD propriétaire.

A+

En matière de volume j'ai déjà dit mon sentiment. En dessous de :

• 100 Go pour l'ensemble des bases
• 100 utilisateurs
• et avec un serveur correct de moyenne gamme : 2 CPU, 16 Go RAM, 4 disques en 2 gappes RAID 11 (minimum)
• et pour une application transactionnelle de complexité moyenne

pas d’hésitation.

Mais, pour le décisionnel, la haute dispo, les bases de plus de 100 Go (ou un serveur avec plus de 250 Go de BD), plus de 100 users, une fonctionnalité inexistante de PG... Y'a pas photo.

Deux petits exemples ou il n'existe aucun équivalent sous PG :

• les mécanismes de CDC (Change Data Capture) présent sur Oracle ou SQL Server
• le mécanisme d'audit de SQL Server qui permet de tracer toutes le DML/DDL (y compris le SELECT) sur les comptes utilisateurs que l'on veut
• Ces deux mécanismes n'étant pas intrusifs (pas de trigger)

Cela dit PG évolue et il y a 3 ans, j'en étais même pas à envisager plus de 20 Go sur une base PG !
Mais la concurrence évolue aussi...

A +

[SQLpro]

SQLPro déplore l'absence de sous-transactions. Je n'ai pas d'expérience de cette fonctionnalité sur un autre SGBD.

Je ne parle pas de sous transactions. Cela n'existe pas; Par nature une transcation étant atomique, soit elle existe soit il n'y en as pas.

Je parle du pilotage de la transaction.!

Puis-je faire

Code :

1
2
3
4
BEGIN TRANSACTION
du code
COMMIT
du code

Dans une function PG ?
Non !

Et pourtant je vous donne un exemple ou cela me serait particulièrement nécessaire (et dans certaines organisation INDISPENSABLES).
Je veut tracer les INSERT/UPDATE/DELETE sur une table, MEME EN CAS DE ROLLBACK lié par exemple au viol d'une contrainte, afin de savoir qui à tenté de faire ça...

Dites moi comment faire sous PG ?

A +

[estofilo]

Envoyé par SQLpro

Et pourtant je vous donne un exemple ou cela me serait particulièrement nécessaire (et dans certaines organisation INDISPENSABLES).
Je veut tracer les INSERT/UPDATE/DELETE sur une table, MEME EN CAS DE ROLLBACK lié par exemple au viol d'une contrainte, afin de savoir qui à tenté de faire ça...

Dites moi comment faire sous PG ?

Typiquement, le code qui logge l'erreur en base va contourner l'impossibilité de toucher à la transaction en cours en ouvrant à l'intérieur de la fonction une autre connexion dédiée au log de l'erreur.
La gestion de connexion à l'intérieur de fonctions se fait avec dblink.

[frost242]

Envoyé par SQLpro

Dites moi comment faire sous PG ?

Effectivement, c'est impossible en l'état. A moins d'utiliser la bidouille citée ci-dessus.

[estofilo]

Envoyé par CinePhil

Cependant, je ne considère pas cette discussion comme un troll, encore moins hiideux

J'utilise ce terme pour qualifier l'article à l'origine de la discussion et non la discussion elle-même. La discussion est le lieu d'un débat alors que l'article lui-même n'est amendable que par la bonne volonté de son auteur car chacun écrit ce qu'il veut sur son blog.

Pour resituer le problème que me pose l'article prenons un autre exemple:

"12 - Pas de compression ni de cryptage des données
PostGreSQL ne permet pas de compresser les données à aucun moment"

Or il est factuel que postgresql compresse de manière transparente les contenus typés text et bytea dès qu'ils dépassent une certaine taille, et ce depuis très longtemps

Sachant cela, l'affirmation péremptoire qu'il n'y a aucune compression ne passe pas, désolé. Et ça n'est qu'un exemple, il y a tellement de points problématiques que celui-là était passé aux oubliettes initialement.

[SQLpro]

Une telle compression de blob ou de varchar est supporté depuis longtemps par tous les GBBDR. Je parle de la compression de toutes les données d'une base par des algorithmes du genre hoffnung par exemple.

A +

[scheu]

Envoyé par estofilo

Typiquement, le code qui logge l'erreur en base va contourner l'impossibilité de toucher à la transaction en cours en ouvrant à l'intérieur de la fonction une autre connexion dédiée au log de l'erreur.
La gestion de connexion à l'intérieur de fonctions se fait avec dblink.

Pour avoir personnellement testé l'utilisation du dblink pour pallier à l'absence de transactions autonomes sous PG, je peux vous dire que ça plombe les performances, que j'ai parfois eu des problèmes de timeouts ou de sessions figées ou trop longues, et que je ne le conseille pas. Alors oui peut-être que c'était résolvable mais pas le temps de passer 3 jours à chercher. En entreprise on veut un produit qui marche quand on l'installe, pas un produit sur lequel il faut être DBA + expert réseau + expert système et installer soi-même les rustines

Ca reste pour moi une bidouille impensable dans un environnement critique de production, tout comme peuvent l'être aujourd'hui le partitionnement ou les pseudos paramètres remplaçant les hints, que j'ai aussi testé, pour lesquels des gens apparamment pro-Postgresql m'ont aussi dit que c'était faisable, et au final en grattant un peu je me suis rendu compte que ce n'était pas une alternative sérieuse aux SGBD payants.

J'avais par exemple il y a quelques temps utilisé pg_rman, qui faisait en théorie (d'après la pub faite) la même chose que le RMAN d'Oracle, à savoir un outil de sauvegarde/restauration à chaud PITR.
Je l'ai testé 2 heures : pg_rman n'était même pas capable de trouver la bonne sauvegarde full pour rejouer les logs afin d'arriver à une heure de sauvegarde ...
Ca donne un peu un sentiment de publicité mensongère ...

auto_explain c'est bien mais ça ne montre pas les plans d'exécution en cours, juste ceux des requêtes terminées, du coup quand une requête est longue impossible de savoir pourquoi, ni quand elle va se terminer

Le discours des pro-Postgresql disant "telle ou telle fonctionnalité d'un SGBD payant n'existe pas sous Postgresql mais on peut quand-même le faire sous PG en bidouillant de telle manière, en jouant sur tel paramètre ou en installant telle ou telle contrib version 1.0", c'est précisément ce genre de discours qui me refroidit à conseiller Postgresql pour des applis volumineuses, critiques ou complexes : le discours sonne un peu trop commercial à mon goût

Je trouve plus objectif des discours comme ceux de frost242, qui reconnaît par exemple que telle fonctionnalité n'existe pas encore sous PG, mais qu'elle est en cours de développement dans une future version

Mon sentiment aujourd'hui concernant Postgresql est qu'il est sur la bonne voie, qu'il peut déjà concurrencer des SGBDs payants pour des applis peu complexes, peu volumineuses et peu critiques, mais pas dans les autres cas

Envoyé par CinePhil

à partir de quel niveau de complexité il est recommandé de passer à un SGBD propriétaire.

Je dirais (c'est mon avis qui n'engage que moi) qu'à partir de 100 Go ou plus, avec des requêtes faisant des jointures complexes (au moins 5 tables), Postgresql montre ses limites. Après ça dépend des cas de figure, de l'utilisation de la base, de l'application, ... C'est impossible d'avoir des chiffres exacts

Dernier point vaguement évoqué au début des commentaires mais très important à mes yeux : la version payante de Postgresql, "Enterprise DB", embarque des fonctionnalités importantes comme les hints, l'équivalent du Enterprise Manager d'Oracle, etc ... ce qui laisse à penser que jamais ces fonctionnalités, pourtant réclamées par beaucoup, ne seront disponibles dans la version gratuite communautaire
Donc au final si c'est pour choisir Postgresql qu'on pense gratuit parce que les SGBDs payants sont trop cher et qu'on ne veut plus être dépendant d'un éditeur et de ses changements de tarif (Oracle pour ne pas le citer), pour au final se rendre compte des limitations de Postgresql et s'entendre dire "c'est possible sur la version payante Enterprise DB, c'est X euros l'achat, X euros le support annuel et vous êtes dépendant de l'éditeur Enterprise DB" ...
Ben au final si on avait eu mieux connaissance de la chose au départ on aurait peut-être choisi une version standard de Oracle ou SQL Server, qui sont des produits intégrant toutes les fonctionnalités qui nous manquaient, bien qu'un peu plus cher qu'Enterprise DB
D'ailleurs si je ne dis pas de bêtises, certains développeurs travaillent simultanément sur la version gratuite et la version payante, donc on peut même supposer que la version Postgresql gratuite est faite pour "appâter" les clients pour les amener à terme sur Enterprise DB ... En tout cas quand on creuse un peu ça y ressemble ...

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 ...

C'est valable pour tout produit open-source, pas seulement les SGBDs, et sur ce point mon avis se rapproche plutôt de celui de SQL Pro, à savoir que parfois l’extrémisme des pro-opensource, qui diabolisent facilement le payant, nuit à avoir un avis réellement objectif et adapté aux réalités des entreprises et du marché

[frost242]

Envoyé par scheu

D'ailleurs si je ne dis pas de bêtises, certains développeurs travaillent simultanément sur la version gratuite et la version payante, donc on peut même supposer que la version Postgresql gratuite est faite pour "appâter" les clients pour les amener à terme sur Enterprise DB ... En tout cas quand on creuse un peu ça y ressemble ...

Non ! Un certain nombre de développeurs travaillent effectivement pour EnterpriseDB (Bruce Momjian, Heikki Linnakangas, etc.), d'autres travaillent pour 2ndQuadrant (Simon Riggs, contributeur majeur), d'autres pour PGExperts, d'autres pour VMWare, AsterData, etc. Un contributeur majeur bosse pour pour Red Hat (Tom Lane, monsieur optimiseur). On n'y pense pas forcément, mais NTT, l'opérateur télco japonais, contribue beaucoup.

C'est peut-être une vision que tu peux avoir, mais est fausse. La page suivante liste les principaux contributeurs au projet: Contributor Profiles.

Et encore une fois, dans l'esprit du projet, les outils style enterprise manager sont plutôt des contributions externes au projet. Vous n'aurez pas un tout fournie clé en main avec PostgreSQL, vous devrez construire votre système en fonction de vos besoins.

D'ailleurs, pour la petite histoire, VMWare offre depuis peu leur propre déclinaison de PostgreSQL, ainsi qu'une console OEM-like.

[scheu]

Envoyé par frost242

Non ! Un certain nombre de développeurs travaillent effectivement pour EnterpriseDB (Bruce Momjian, Heikki Linnakangas, etc.), d'autres travaillent pour 2ndQuadrant (Simon Riggs, contributeur majeur), d'autres pour PGExperts, d'autres pour VMWare, AsterData, etc. Un contributeur majeur bosse pour pour Red Hat (Tom Lane, monsieur optimiseur). On n'y pense pas forcément, mais NTT, l'opérateur télco japonais, contribue beaucoup.

C'est peut-être une vision que tu peux avoir, mais est fausse. La page suivante liste les principaux contributeurs au projet: Contributor Profiles.

Autant pour moi je n'étais pas sûr, merci pour cette précision

Envoyé par frost242

Et encore une fois, dans l'esprit du projet, les outils style enterprise manager sont plutôt des contributions externes au projet. Vous n'aurez pas un tout fournie clé en main avec PostgreSQL, vous devrez construire votre système en fonction de vos besoins

Cela confirme le fait que les fonctionnalités telles que les HINT ne seront sans doute jamais implémentées dans la version gratuite, si elles sont justement l'apport de la version payante

On ne peut pas dire d'un côté, Postgresql peut, en entreprise, remplacer un SGBD payant, et admettre implicitement d'un autre côté que certaines fonctionnalités cruciales pour les entreprises ne sont disponibles qu'avec la version payante.

Le problème avec Postgresql c'est qu'en lisant juste la doc "commerciale" on a l'impression que ce SGBD fait tout aussi bien qu'Oracle ou SQL Server, et c'est après qu'on peut déchanter
Ca confirme donc mon sentiment que pour des applications critiques, complexes ou volumineuses, Postgresql est encore au jour d'aujourd'hui trop limité

[frost242]

Sans aller dans l'offre payante, il existe tout de même quelques outils libres:
- pgAdminIII qui n'est pas si mal que ça
- pg_statsinfo pour avoir un AWR
- pg_reporter couplé à l'outil précédent qui vous offre une console Web

[JeitEmgie]

Une question que soulève cet article, au-delà de petites erreurs factuelles mineures, c'est de savoir à qui s'adresse-t-il réellement ?

S'il serait facile de comprendre l'intérêt d'un article qui aborderait la problématique inverse :
à quoi sert réellement d'étaler les truismes que n'importe qui aurait fait le choix raisonné de SGBD comme DB2, ORACLE, MSSQL-Server est censé connaître ?

Qui ici a déjà rencontré sérieusement cette problématique de devoir envisager la descente vers un outil moins performant ?
Autant la question de savoir "quand sera-t-il nécessaire de passer à un outil plus performant, d'upgrader nos configurations, …" est posée régulièrement : combien de fois avez-vous rencontré le problème inverse en dehors de problématiques ponctuelles de décharger un SGBD pour des travaux secondaires ou décentralisés dans l'entreprise ?

Dès lors quelles sont les motivations pour taper inutilement sur PostgreSQL ?
Craindre que les gens qui investissent dans cet outil considèrent plus facilement ORACLE que MSQL-Server comme choix logique lorsque la nécessité s'en fera sentir ?

[scheu]

Envoyé par JeitEmgie

Une question que soulève cet article, au-delà de petites erreurs factuelles mineures, c'est de savoir à qui s'adresse-t-il réellement ?

S'il serait facile de comprendre l'intérêt d'un article qui aborderait la problématique inverse :
à quoi sert réellement d'étaler les truismes que n'importe qui aurait fait le choix raisonné de SGBD comme DB2, ORACLE, MSSQL-Server est censé connaître ?

Qui ici a déjà rencontré sérieusement cette problématique de devoir envisager la descente vers un outil moins performant ?
Autant la question de savoir "quand sera-t-il nécessaire de passer à un outil plus performant, d'upgrader nos configurations, …" est posée régulièrement : combien de fois avez-vous rencontré le problème inverse en dehors de problématiques ponctuelles de décharger un SGBD pour des travaux secondaires ou décentralisés dans l'entreprise ?

Dès lors quelles sont les motivations pour taper inutilement sur PostgreSQL ?
Craindre que les gens qui investissent dans cet outil considèrent plus facilement ORACLE que MSQL-Server comme choix logique lorsque la nécessité s'en fera sentir ?

L'intérêt de ce topic est justement de montrer les limites de Postgresql comparé aux SGBDs payants, et d'évaluer si ces limites peuvent être gênantes ou pas en fonction du besoin
Je trouve plus honnête de dire aux gens "attention si vous migrez de SQL Server à Postgresql, il y aura un risque sur ça, ça et ça, à vous de voir si ça peut vous gêner selon votre utilisation" que de dire "allons-y, migrons, il n'y a aucun risque"

J'ai déjà exprimé mon avis (qui n'engage que moi)