Vous n'êtes pas identifié(e).
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 !
Hors ligne
En fait le problème de sqlpro c'est que pour utiliser correctement postgresql il faut des bons dba et admins system 
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 ? )
Dernière modification par kenrio (12/10/2011 16:02:27)
Hors ligne
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
[...]
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 +
Dernière modification par SQLpro (16/10/2011 14:01:32)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
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 +
Hors ligne
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 +
Julien.
https://rjuju.github.io/
Hors ligne
Je suis quand-même atterré devant tant de dénigrement de l'article de SQL Pro (que je ne connais pas personnellement je précise).
Vous avez l'air de le faire passer pour un commercial intéressé pour vendre ses bouquins, alors qu'il ne renvoie que vers des liens internet ou vers des articles publics gratuits
Vous voulez le faire passer pour un perturbateur qui ne dit que des sottises, c'est méconnaître tous les articles qu'il a déjà pu publier notamment sur developpez.com
Alors oui sur le forum officiel de Postgresql vous êtes peut-être en majorité, mais cela ne doit pas interdire de pouvoir débattre sans que ça tourne au lynchage
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
Dernière modification par scheu.postgresql (17/10/2011 15:57:40)
Hors ligne
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
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.
Guillaume.
Hors ligne
