Et venant de la part de personnes d'une société (Dalibo) faisant des prestations sur Postgresql, je ne suis pas certain que votre avis soit plus objectif que celui de SQL Pro pour reconnaître les quelques lacunes que Postgresql peut encore avoir aujourd'hui comparé aux SGBD payants
En gros l'article de SQL Pro n'est pas anti-Postgresql, il dit que Postgresql peut remplacer un SGBD payant dans beaucoup de cas, mais n'est pas encore suffisamment "mature" pour des applications volumineuses, critiques ou complexes
Etant personnellement DBA en entreprise avec plusieurs années d'expérience Oracle et Postgresql (avec migrations effectuées de l'un à l'autre), je suis entièrement d'accord avec cela
D'ailleurs SQL Pro a précisé ses arguments sur cette discussion pour ceux qui ne l'auraient pas lu et/ou critiquent ses arguments :
http://www.developpez.net/forums/d11409 … l-ecueils/
L'optimiseur Postgresql a encore de grosses lacunes pour des requêtes complexes
Vous parlez par exemple de hints dans les précédents commentaires, et bien oui les hints, bien que leur utilisation doit rester exceptionnelle, sont indispensables sur une application critique.
Quand du jour au lendemain, sur une requête complexe (jointure avec au moins 5-6 tables), votre plan d'exécution change et votre batch en production utilise le mauvais index, consomme 100% de CPU pendant 3 heures et non plus 5 minutes, vous vous en sortez comment ?
En achetant un nouveau CPU ?
Ben sur un SGBD payant vous mettez un hint et en 2 minutes vous éteignez le feu. Je me vois mal dire au DSI "oui mais c'est au développeur à modifier sa requête ou à tel éditeur à modifier la requête dans son progiciel, ça prendra 1 semaine minimum"
Même les paramètres tels que enable_nestedloop, enable_seqscan, ... ne suffisent pas à s'en sortir
Le principal défaut de l'optimiseur Postgresql est qu'il sous-estime trop souvent les cardinalités (nombre de lignes retournées à chaque étape du plan), ce qui conduit au bout d'un moment :
- soit à lui faire choisir des "nested loop" au lieu de "hash join" en cas de jointure
- soit à des "index range scan" trop coûteux alors qu'un full scan de la table serait au final meilleur
Je pense que ce problème est lié au fait que Postgresql sait très mal évaluer les nombres de lignes retournés pour des filtres qui comportent plusieurs colonnes
Là où Oracle ou SQL Server, sur un index (col1,col2,col3), sait faire des stats dessus et savoir estimer, pour chaque valeur du triplet, le nombre de lignes dans la table, Postgresql ne sait le faire que dans de très rares cas, les histogrammes se limitant sur des colonnes uniques et pas des t-uples
Quand, dans un autre exemple, on explique que pour pallier à l'absence de transactions autonomes il faut créer un dblink de la base sur elle-même, ça ressemble plus à une bidouille qu'autre chose.
Idem pour le partitionnement (dans un autre sujet de ce forum), qui en est encore au stade préhistorique sur Postgresql, alors que si on ne lit que les commentaires des pro-Postgresql, on a l'impression que c'est simple et génial, et qu'on va pouvoir migrer demain notre décisionnel de 500 Go sous Postgresql. Alors que c'est encore loin d'être le cas
Autre exemple au hasard : quand une requête est longue, impossible de savoir ni pourquoi, ni quand elle va se terminer, ni le plan d'exécution qu'elle a (on doit attendre qu'elle se termine pour le voir dans la log avec auto_explain)
Sérieusement sur un environnement critique et volumineux en entreprise vous croyez vraiment que c'est suffisant ?
Je ne trouve pas très honnête de conseiller Postgresql aux entreprises sans parler des mises en garde pour des applications critiques et volumineuses (au moins ça peut faire vendre de la prestation pour venir corriger les problèmes chez le client après coup ...)
La plupart des détracteurs ici n'ont même pas l'air de connaître lmes fonctionnalités de SQL Server ou Oracle, après comment être crédibles pour expliquer que Postgresql n'a rien à leur envier ?
J'aurais espéré de la part de Dalibo et des membres de la communauté Postgresql une réponse un peu moins commerciale et un peu plus honnête du genre "oui effectivement Postgresql a encore du retard sur certaines fonctionnalités, c'est encore compliqué à utiliser et peu performant, mais dans une prochaine version ça va être amélioré", ça aurait été plus objectif.
Mais là je ne suis pas certain que ça renforce votre crédibilité
A tout hasard, j'ai un décisionnel de 1 To sous Oracle 10g avec
- des jointures sur 10 tables
- du partitionnement
- du sous-partitionnement
- de la compression d'anciennes partitions dans des tablespaces en lecture seule
- quelques hints car parfois même Oracle se plante pour des requêtes ultra-complexes
A vous écouter demain je le migre sans problèmes sur Postgresql 9.1 c'est ça ? Et ne me répondez pas oui, vous savez très bien que c'est impensable dans la version actuelle de Postgresql
A titre personnel en tout cas, je maintiens mon sentiment initial qui est que Postgresql ne peut pas (encore) remplacer un SGBD payant sur des applications volumineuses ou critiques (données accessibles 24h/24 sans verrous) ou complexes (requêtes dépassant les 4-5 jointures)
Alors que je conseille Postgresql dans les cas inverses, ça fait très bien l'affaire et ça fait faire des économies : j'encourage Postgresql quand ça répond au besoin, je ne suis pas anti-Postgresql bien au contraire
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
PS : Monsieur Damien Clochard, je ne suis pas certain que vos interventions à base d'images font avancer le débat ... néanmoins je vous souhaite une bonne journée
Salutations
]]>ioguix a écrit :[...]
En attendant, plutôt que de détailler et insister sur les (je cite) "grandes lacunes de PostgreSQL", vous pourriez plutôt titrer "Obstacles et différences à prévoir lors d'une migration vers PostgreSQL" et les façons de les contourner ou alors bien souvent...l'autre façon de faire dans le monde PostgreSQL.
[...]Dommage, si vous passiez un quart de votre temps actuel accordé au pourissage pour écrire des choses constructives ou à participer de façon constructive à la communauté, on vous aurait peut-être cru quant à vos bons sentiments envers PostgreSQL.
Selon vous je ne devrais faire que des articles positif sur PostGreSQL et ne jamais parler de choses qui fasse... C'est amusant. Je ne sais pas pourquoi, mais cela me rappelle certains époque comme celle de l'URSS.
De plus et contrairement à ce que vous pensez j'agit dans les deux sens : critique + aide, mais il semble que vous ne lisiez que mes critiques..
Voici quelques un des articles "positifs" :
SQL et système d'information géographique (SIG)
Contraintes CHECK sur tables externe avec PostGreSQL
UDF POSTGRESQL : créer des fonctions PL/pgSQL avec de nombreux exemples - PARTIE 1 - fonctions scalairesA +
]]>
Selon vous je ne devrais faire que des articles positif sur PostGreSQL et ne jamais parler de choses qui fasse... C'est amusant. Je ne sais pas pourquoi, mais cela me rappelle certains époque comme celle de l'URSS.
A +
]]>
[...]
En attendant, plutôt que de détailler et insister sur les (je cite) "grandes lacunes de PostgreSQL", vous pourriez plutôt titrer "Obstacles et différences à prévoir lors d'une migration vers PostgreSQL" et les façons de les contourner ou alors bien souvent...l'autre façon de faire dans le monde PostgreSQL.
[...]Dommage, si vous passiez un quart de votre temps actuel accordé au pourissage pour écrire des choses constructives ou à participer de façon constructive à la communauté, on vous aurait peut-être cru quant à vos bons sentiments envers PostgreSQL.
Selon vous je ne devrais faire que des articles positif sur PostGreSQL et ne jamais parler de choses qui fasse... C'est amusant. Je ne sais pas pourquoi, mais cela me rappelle certains époque comme celle de l'URSS.
De plus et contrairement à ce que vous pensez j'agit dans les deux sens : critique + aide, mais il semble que vous ne lisiez que mes critiques..
Voici quelques un des articles "positifs" :
SQL et système d'information géographique (SIG)
Contraintes CHECK sur tables externe avec PostGreSQL
UDF POSTGRESQL : créer des fonctions PL/pgSQL avec de nombreux exemples - PARTIE 1 - fonctions scalaires
A +
]]>Vous payer microsoft ou oracle pour vous pondre des outils de monitoring, des outils d'optimisations, etc ... pourquoi tout simplement car les admins windows et dba microsoft sont ultra limités et la plus part mauvais
Et puis ce qui est bien avec microsoft ou oracle c'est que quand il y a un problème on demande à microsoft de nous trouver l'erreur, c'est pas trop dur ( quand ils trouvent biensur ^^ ce qui n'est pas toujorus le cas lol ? )
]]>C'est bien de critiquer sans avoir lu ! Cela montre le niveau des intégristes de PostGreSQL... A quand le tchador ?
A +
Etant donnée les titres de votre sommaire et connaissant assez bien vos interventions/troll poilues (NG bases de données, logiciels libre, ce forum, ...), je ne vois pas l'intérêt de lire cette chose. Je ne suis pas intégriste, la preuve : je vous parle ... mais ça commence à me fatiguer de vous voir critiquer tout et n'importe quoi !
]]>Vous vous entêtez dans l'erreur, continuez votre dénigrement et assénez des contre-vérités plus vite que votre ombre, ce qui soit dit en passant, me faisait plutôt rire.
Mais là, vous dépassez clairement les bornes avec des propos islamophobes. Ça ne me fait plus rire du tout.
Sachez que de les propos xénophobes ne sont pas acceptables, ni sur ce forum public, ni ailleurs. Ils sont purement et simplement condamnables.
Autant vous pouvez dire toutes les bêtises sur PostgreSQL que vous voulez, car nous serons là pour les démentir, autant ces propos xénophobes vous font passer directement de la case "amuseur public" à la case "utilisateur à bannir".
Je vous conseille d'éviter ce genre de propos à l'avenir sur internet, en particulier sur des forums publics comme celui-ci, car cela pourrait vous amener directement à la case "Prison".
J'ai sollicité par mail l'ensemble des administrateurs du forum pour que nous puissions prendre une décision d'exclusion à votre encontre. Comprenez bien que nous devons assurer la bonne tenue de ce forum d'entraide, et que cela passe par des décisions radicales lorsque cela est justifié, comme c'est le cas aujourd'hui.
Bien que nous soyons d'ardents défenseurs de la liberté d'expression, ne nous pouvons tolérer de tels propos.
Au revoir,
]]>Moi, je vais m'installer confortablement devant ma mailing-list pgsql-hackers, prendre des popcorn et regarder si vous aurez des arguments différents de tous ces autres. À moins qu'ils vous balaient avec dédains en vous renvoyant à un simple lien [1] comme n'importe quel quidam...
En attendant, plutôt que de détailler et insister sur les (je cite) "grandes lacunes de PostgreSQL", vous pourriez plutôt titrer "Obstacles et différences à prévoir lors d'une migration vers PostgreSQL" et les façons de les contourner ou alors bien souvent...l'autre façon de faire dans le monde PostgreSQL.
Si je prends l'exemple des tablespaces, contrairement à Oracle, les développeurs de PostgreSQL ont décidés de ne pas ré-implémenter la roue. Il y a bien mieux à faire ailleurs. Ça vous demandera d'ôter vos œillères et aller voir coté système les solutions qui existent pour assurer le même type de souplesse...
Dommage, si vous passiez un quart de votre temps actuel accordé au pourissage pour écrire des choses constructives ou à participer de façon constructive à la communauté, on vous aurait peut-être cru quant à vos bons sentiments envers PostgreSQL.
]]>Ce devient n'importe quoi ...
je ne suis pas administrateur, mais je me demande ce que Mr SQLPro (?!) fait sur ce forum.
Je ne vois pas l’intérêt de venir ici pour dénigrer Postgresql et vendre sa soupe (articles, blog, livres, SQLServer, ...).
Ce forum a pour objectif d'aider les gens, pas de passer son temps à troller sur des moteurs de base de données qui ne nous intéressent pas !
Je ne vais pas lire votre article, car le sommaire sonne déjà comme un appel au troll et est déjà complètement faux.Y a t'il une option ignorer dans ce forum ?
C'est bien de critiquer sans avoir lu ! Cela montre le niveau des intégristes de PostGreSQL...
A +
]]>Pour le point 6, la vue pg_stat_all_indexes sert à quoi ?
Mea culpa, j'ai rectifié le tir !
Merci
A +
]]>Un seul exemple me suffira, puisqu'ensuite je suppose que vous viendrez jouer de mauvaise foi ou répondrez à coté :
Il n'est pas non plus possible de savoir comment sont utilisés les index de la base et donc de supprimer les index inutilisés. Par exemple SQL Server propose la vue sys.dm_db_index_usage_stats pour connaitre l'utilisation de tous les index du serveur.
Il existe la même chose sur postgres, par exemple la vue pg_stat_user_indexes.
Pour votre "culture personnelle" également : http://docs.postgresqlfr.org/9.0/monitoring-stats.html
Là j'avoue que je n'ai effectivement pas vu cela.
Ce qui est dommage c'est que dans ces vues il n'y a pas le nombre de mises à jour d'index que l'on obtient par approximation au niveau table (un index n'est pas forcément mis à jour lors d'un update), ce qui serait très pratique pour décider de retirer ou non l'index.
Malgré cela il n'existe rien pour savoir quels index sont à poser !
A +
]]>