Discussion :

[marc.collin]

est-ce qu'il y aura un test avec une requête optimisé pour postgres avec un résultat déplorable sous ms sql server?

ou bien c'est impossible, ms sql server le surpasse pour quoi?

[esperanto]

Ce qui est dit dans la page que tu cite :
https://use-the-index-luke.com/fr/sq...sql/operations
Contient des erreurs... En effet, l'auteur dit :
"L'opération Index Scan réalise un parcours de B-tree, passe au travers des nœuds feuilles pour trouver toutes les entrées correspondantes, et récupère les données correspondantes de la table"
C'est totalement faux ! Ceci identifie un accès de type range et non scan...

C'est bien pour ça qu'il écrit: "C'est identique à un INDEX RANGE SCAN suivi d'un TABLE ACCESS BY INDEX ROWID. "

Et comme la petite mention sous le titre l'indique "Table des matières › Plans d'exécution › PostgreSQL › " c'est spécifique à PostgreSQL….

OK alors sur le même site je vois: https://use-the-index-luke.com/fr/sq...cle/operations
Ici on parle de RANGE SCAN mais quand tu lis la définition tu retrouves exactement la même chose que ce qui était associé à INDEX SCAN dans la page précédente.
Mais c'est spécifique à Oracle.
Donc: les deux bases utilisent une terminologie différente pour désigner la même chose.

[SQLpro]

- Vos conclusions "SQL Server est 300 000 fois plus rapide que PostGreSQL sur cette recherche insensible aux accents" sont profondément malhonnêtes. Vous laissez comprendre que Postgresql est intrinsèquement mauvais pour résoudre ce problème mais la vérité c'est juste que vous avez trouvé une mauvaise solution au problème et que vous refusez d'utiliser de meilleurs solutions.

Vous me traitez de malhonnête ce qui est à la limite de la diffamation, mais vous ne me montrez aucune solution à la requête du test [T-0060] celle justement qui a une différence de 300 000...
Seriez vous par hasard de mauvaise foi ?

A +

[SQLpro]

est-ce qu'il y aura un test avec une requête optimisé pour postgres avec un résultat déplorable sous ms sql server?

ou bien c'est impossible, ms sql server le surpasse pour quoi?

Question philosophique… pourquoi croyez vous que je gens payent du Oracle ou du SQL Server ? Parce que les entreprises aiment jeter leur argent par les fenêtres ? S'il n'y avait pas un intérêt, notamment en terme de performances, tout le monde prendrait PostgreSQL et Microsoft comme Oracle auraient fait faillite. Or ce n'est pas le cas...

Dans le benchmark sur le spatial, les requêtes Q2 et Q4 sont meilleures avec PostgreSQL…

Quand à trouver des résultats ou PostgreSQL explose les performances par rapport à SQL Server, j'avoue en avoir rarement rencontré en prod… Peut être parce que je ne pratique PostgreSQL pas suffisamment…. Mais je me souvient que du temps d'avant la version 2016, SQL Server ne disposait pas de la fonction STRING_AGG et on était obligé de passer par du XML pour ce faire, alors que PostgreSQL l'implémentait… Dans ce cas, les différences étaient très sensibles !

A +

[SQLpro]

...
Donc: les deux bases utilisent une terminologie différente pour désigner la même chose.

C'est pour cela que je vous renvoie sur les papiers fondamentaux de recherche ou la terminologie est précise et en dehors de toute considération commerciale !

Vous noterez que je vous ai mis un + !

A +

[Sodium]

Crier à la diffamation c'est vraiment le bas du bas des derniers degrés de recours quand on sait qu'on perd un débat

Question philosophique… pourquoi croyez vous que je gens payent du Oracle ou du SQL Server ? Parce que les entreprises aiment jeter leur argent par les fenêtres ? S'il n'y avait pas un intérêt, notamment en terme de performances, tout le monde prendrait PostgreSQL et Microsoft comme Oracle auraient fait faillite. Or ce n'est pas le cas...

Peut-être parce que Microsoft et Oracle font du démarchage auprès des entreprises et pas les solutions open-source..

[marc.collin]

Question philosophique… pourquoi croyez vous que je gens payent du Oracle ou du SQL Server ? Parce que les entreprises aiment jeter leur argent par les fenêtres ? S'il n'y avait pas un intérêt, notamment en terme de performances, tout le monde prendrait PostgreSQL et Microsoft comme Oracle auraient fait faillite. Or ce n'est pas le cas...

A +

j'ai arrêté de compté les fois où des licences étaient acheté mais que le produit n'était directement pas utilisé
ou bien que le produit choisie était un exagé pour les besoins

tel qu'oracle doit être utilisé car l'entreprise à beaucoup de donnée... et que tu te rends compte que beaucoup c'est même pas 10gig...

des décideurs pressés, c'est pas ça qui manque dans cette industrie

[fredoche]

Bonjour
je vais me mêler de ce qui ne me regarde pas mais c'est pas grave.

J'ai un très grand respect pour SQLPro dont j'apprends depuis 20 ans à partir de ses cours et nombreux articles.

A la question pourquoi SQL Server ou Oracle, il serait bien que tu y répondes.
J'ai déjà fait remarquer il y a quelques temps ici en lisant les CGU de SQL Server 2016 Web que comme pour tous les produits microsoft, Micrtosoft décline toute responsabilité sur la conséquence de l'utilisation de ses produits. Ça commence basiquement par Windows, server ou non.
Moi j'ai peur que ce soit juste des grands noms de l'industrie, du bon marketing, et des développeurs qualifiés sur ces produits qui justifient ça. Et quand tu es décideur, tu prends rarement des risques. Et à partir de là on peut développer, notamment sur ces risques qu'on croit ne pas prendre.

quand je lis :

Dans le cadre d'un long article à paraître dont le sujet est l'étude de la portabilité de bases Microsoft SQL Server vers PostGreSQL, j'ai été amené à effectuer des tests comparatifs.

Je publie ici un exemple concernant d'importantes différences de performances concernant les manipulation de chaines de caractères et notamment dans le cadre de recherches avec insensibilité à la casse ou aux accents.

Donc je lis les requêtes, les jeux de données et je me pose quelques questions :
Quel rapport avec une situation réelle ?
Cet article sent très fort l'article partial, à charge, biaisé, comme on veut... On parle d'une situation réelle, de vraies bases et d'une vraie base de code que l'on va porter ?
Ou bien c'est juste un scénario imaginaire qui va permettre de démontrer ce que l'on souhaite démontrer pour la rédaction de cet article ?

Ne pas réécrire de code ?
Je suis désolé mais quand on a une application, que le code relatif à la BDD soit coté langage applicatif ou coté BDD, j'entends par là pas seulement les requêtes mais aussi tout ce qui est procédures stockées, curseurs, vues, triggers...
Bref dans quel cas c'est réellement portable sans réécriture de code ? En vrai parce que déjà la requête donnée en exemple est déjà obligée d'incorporer un "LOWER"

Franchement... Pour n'utiliser que du SQL server je sais très bien que le moindre portage m'obligerait à repenser la base de code. Parce que évidemment quand je cherche à faire un truc, j'utilise cet outil et ses spécificités. Et la vie réelle d'une appli c'est rarement juste des select et des insert.
Enfin je sais pas quand on prend un produit comme drupal qui est censé pouvoir fonctionner aussi bien sur mysql que postgreSQL, on indique à l'installation ce que l'on va utiliser. On va pas juste changer un lien ODBC comme ça...
Ça rime à quoi tout ça ?

[SQLpro]

... Peut-être parce que Microsoft et Oracle font du démarchage auprès des entreprises et pas les solutions open-source..

Pour PostGreSQL pas besoin de démarchage commercial, vu le lobbying que tu fais !

Pour ce qui est de l'Open Source, Microsoft est l'un des plus gros contributeur.... Donc tu peut lui dire merci, même si ça te fais mal au cul !
https://www.infoworld.com/article/32...en-source.html
https://www.freecodecamp.org/news/th...-be98ab854e87/

Microsoft ayant finalement décidé d’ouvrir complétement .net en 2015 du fait que les contributions externes devenaient plus importantes que le code réalisé en interne par les équipes de MS/
https://devblogs.microsoft.com/dotne...source-update/

A +

[SQLpro]

... J'ai déjà fait remarquer il y a quelques temps ici en lisant les CGU de SQL Server 2016 Web que comme pour tous les produits microsoft, Micrtosoft décline toute responsabilité sur la conséquence de l'utilisation de ses produits. Ça commence basiquement par Windows, server ou non.

Ceci est en partie vraie et en partie faux.
https://www.microsoft.com/fr-fr/store/b/aboutwarranties

Tous les constructeurs, éditeurs et autres prestataires mettent des limites dans leurs contrats... Cependant il y a la Loi qui impose le défaut de vice caché.... et donc l'engagement de responsabilité ! C'est pour cela d'ailleurs que toute entreprise est obligé de prendre une assurance RC pour le cas ou...

...
Donc je lis les requêtes, les jeux de données et je me pose quelques questions :
Quel rapport avec une situation réelle ?
Cet article sent très fort l'article partial, à charge, biaisé, comme on veut... On parle d'une situation réelle, de vraies bases et d'une vraie base de code que l'on va porter ?
Ou bien c'est juste un scénario imaginaire qui va permettre de démontrer ce que l'on souhaite démontrer pour la rédaction de cet article ?

C'est un extrait très court d'un article qui contient déjà plus de 90 pages word..... Vous me jugez déjà sur 1% de la chose ?...

Ne pas réécrire de code ?
Je suis désolé mais quand on a une application, que le code relatif à la BDD soit coté langage applicatif ou coté BDD, j'entends par là pas seulement les requêtes mais aussi tout ce qui est procédures stockées, curseurs, vues, triggers...

C'est là tout l'enjeu de l'article que j'écris... Ou régler le curseur entre 10 % de modif à faire ou 90... ?

Bref dans quel cas c'est réellement portable sans réécriture de code ? En vrai parce que déjà la requête donnée en exemple est déjà obligée d'incorporer un "LOWER"

C'est bien le problème !

Franchement... Pour n'utiliser que du SQL server je sais très bien que le moindre portage m'obligerait à repenser la base de code. Parce que évidemment quand je cherche à faire un truc, j'utilise cet outil et ses spécificités. Et la vie réelle d'une appli c'est rarement juste des select et des insert.

J'ai commencé à écrire cet article suite à la demande d'un de mes clients qui voulait porter une application critique (ERP interne) vers PostGreSQL...

A +

[marc.collin]

C'est là tout l'enjeu de l'article que j'écris... Ou régler le curseur entre 10 % de modif à faire ou 90... ?

dans vos milliers de contrat, c'est arriver combien de fois de devoir absolument rien modifier?

[Sodium]

Je ne fais pas du lobbying Postgres. Je bosse sous Postgres, MariaDB, Sqlite ou Informix selon les projets. Je me moque juste des personnes qui sous couvert d'une pseudo-réputation se permettent d'écrire n'importe quoi et débordent de mauvaise foi pour chercher à valider leurs conviction personnelles.

[StringBuilder]

dans vos milliers de contrat, c'est arriver combien de fois de devoir absolument rien modifier?

Sur des petites applications, ça m'est arrivé énormément de fois.
Heureusement, le SQL est normé, et la syntaxe de création des vues change généralement pas ou peu d'un SGBD à l'autre.

Après, le portage du langage de script peut parfois être automatisé, mais sur un petit projet, il n'y en a généralement pas ou peu.

Enfin, vous oubliez que quand on décide de porter ou non une application, avant de savoir si on va bien le faire, il y a surtout la question de "est-ce que ça vaut le coût" ?

A savoir que si c'est pour économiser 5000 euros de licences tous les 5 ans, est-ce que ça vaut le coup d'y passer 20 jours ? (je parle bien d'un petit projet)

Car le problème est bien là aujourd'hui : le "seul" véritable intérêt d'utiliser PostgreSQL, MariaDB ou autre SGBD open source, c'est avant tout pour le coût des licences, et de la maintenance. Si au final ça coûte plus cher à porter puis à maintenir... c'est peut-être pas si bête de payer une licence... Ça s'appelle un investissement.

[StringBuilder]

Je ne fais pas du lobbying Postgres. Je bosse sous Postgres, MariaDB, Sqlite ou Informix selon les projets. Je me moque juste des personnes qui sous couvert d'une pseudo-réputation se permettent d'écrire n'importe quoi et débordent de mauvaise foi pour chercher à valider leurs conviction personnelles.

Excusez-moi du peu, mais j'ai la forte impression que vous vous décrivez.
Vous ne connaissez rien à SQL Server, donc sur quoi vous basez-vous pour dire qu'il n'est pas meilleur ?

[fredoche]

Enfin, vous oubliez que quand on décide de porter ou non une application, avant de savoir si on va bien le faire, il y a surtout la question de "est-ce que ça vaut le coût" ?

A savoir que si c'est pour économiser 5000 euros de licences tous les 5 ans, est-ce que ça vaut le coup d'y passer 20 jours ? (je parle bien d'un petit projet)

Car le problème est bien là aujourd'hui : le "seul" véritable intérêt d'utiliser PostgreSQL, MariaDB ou autre SGBD open source, c'est avant tout pour le coût des licences, et de la maintenance. Si au final ça coûte plus cher à porter puis à maintenir... c'est peut-être pas si bête de payer une licence... Ça s'appelle un investissement.

C'est peut-être aussi pour ça que le la démonstration de SQLpro n'a guère de sens.
La performance s'évalue de manière globale et en regard de l'application, mais est-ce que c'est vraiment le bon critère de décision ? Probablement pas.

Il y a souvent cette logique en matière d’informatique de comparer les produits sur la base de benchmark. Sauf que ces benchmarks sont souvent simplifiés à l’extrême et peu représentatifs de la diversité des applications.
A cela vient s'ajouter le fait que les matériels aujourd'hui sont très peu couteux, surtout la RAM, et on on sait à quel point c'est un des éléments essentiels

Par contre quand on commence à décliner le petit projet, la petite appli, sur quelques centaines de machines. Hé bien oui les 20 jours de portage seront sacrément bien investis à comparer aux 5000€ multipliés par 100, 1000 ou plus.

Et là encore c'est pas le benchmark brut sur une requête basique qui pourra rendre compte de ça.

Si tous les drupal ou wordpress avaient été développés sur SQL Server, même avec des licences web, je pense que M$ serait très heureux

Et je vois déjà des réponses se profiler du genre "oui mais il y a Express". Ok et c'est bien ça le truc, c'est un schéma de décision multifactoriel pondéré, et pas un benchmark qui dit 300 000 fois plus rapide

[StringBuilder]

C'est peut-être aussi pour ça que le la démonstration de SQLpro n'a guère de sens.

Je pense surtout qu'il y a un procès d'intention à l'encontre de SQLPro.
Comme il l'a expliqué maintes fois, l'article dont est tiré l'extrait en début de topic n'a pas pour vocation de comparer SQL Server et PostgreSQL, mais d'identifier les écueils d'un portage de SQL Server vers PostgreSQL.
C'est à dire que l'article, à priori de plus de 90 pages, est une compilation des contraintes, ou limites, ou autres problématiques liées au portage d'un traitement existant de SQL Server vers PostgreSQL.
Arriver à des conclusions que certaines requêtes sont 300 000 fois plus rapides ou plus lentes n'a rien de choquant : c'est juste qu'il faut garder en tête lors d'un tel portage que si on n'adapte rien, alors on va clairement au devant de gros problèmes (notamment de performances, mais pas que).
Je trouve cet article très utile au contraire, et sert PostgreSQL tout autant que SQL Server : si demain quelqu'un souhaite migrer, il sait quels pièges éviter, et quelles optimisations mettre en place pour pallier aux différences de fonctionnement des deux produits.

Par contre quand on commence à décliner le petit projet, la petite appli, sur quelques centaines de machines. Hé bien oui les 20 jours de portage seront sacrément bien investis à comparer aux 5000€ multipliés par 100, 1000 ou plus.

Là je suis très moyennement d'accord. Les licences SQL Server sont généralement par core, ou parfois par utilisateur (je ne sais même pas si ça existe encore). Mais jamais en nombre de machines y accédant ni en nombre de lignes stockées (sauf si on choisi un hébergement Azure évidement).
Par conséquent, si aujourd'hui j'investis dans un SQL Server Standard Edition et que j'ai 3 pellerins qui s'y connectent, je n'aurai pas un centime de plus à débourser le jour où il y en aura 30... Ni même 300 ou 3000, sauf si le serveur devient juste et que je dois ajouter des cores.
Même pire, si j'ai 50 petits projets, je peux parfaitement tous les héberger sur le même serveur avec une unique licence.

Si tous les drupal ou wordpress avaient été développés sur SQL Server, même avec des licences web, je pense que M$ serait très heureux

Tu l'as vu venir, mais je pense que 99% des drupal ou autres wordpress actuellement en ligne pourraient parfaitement se contenter d'un SQL Server Express. Et j'ai envie de dire... qu'un seul SQL Server Express pourrait parfaitement faire tourner plusieurs dizaines de ces applications sa sourciller.
Après tout, les contraintes de SQL Server Express en terme de mémoire notamment ne sont pas incompatibles avec des sites où tout est sur la même machine, et à mon sens, pour un CMS pas besoin d'une base de donnée de folie...
J'administre quotidiennement des applications clientes avec plus d'une dizaine de bases de quelques Go sur une même instance de SQL Server Express, avec des pics d'utilisation de plusieurs centaines de personnes simultanées, et c'est pas SQL Server qui ralenti quoi que ce soit.

[fredoche]

Mais jamais en nombre de machines y accédant ni en nombre de lignes stockées (sauf si on choisi un hébergement Azure évidement).

Je ne parlais pas de nombre de machines y accédant mais de nombre de machines faisant office de serveur, pour lesquelles une licence sera nécessaire

[SQLpro]

… A cela vient s'ajouter le fait que les matériels aujourd'hui sont très peu couteux, surtout la RAM, et on on sait à quel point c'est un des éléments essentiels

Ha oui, le fameux match muscle contre cerveau…
Problème, tu peut toujours rajouter de la RAM ou du processeur. Mais pour une requête ou PostgreSQL est juste 300 000 fois moins performant, tu vas dire à ton boss, achetez moi 300 000 CPU ou 300 000 Go de RAM ???

A +

[SQLpro]

j'ai arrêté de compté les fois où des licences étaient acheté mais que le produit n'était directement pas utilisé
ou bien que le produit choisie était un exagé pour les besoins

tel qu'oracle doit être utilisé car l'entreprise à beaucoup de donnée... et que tu te rends compte que beaucoup c'est même pas 10gig...

des décideurs pressés, c'est pas ça qui manque dans cette industrie

Je te rejoins là aussi. J'ai souvent prôné PostgreSQL pour des applications basiques et classique de l'entreprise. Exemple paye ou comptabilité. Mais le problème c'est que très peu d'éditeurs ont une version PostgreSQL. Pourtant c'est parfaitement adapté :

• pas une volumétrie énorme
• pas de 24h/24 et 7j/7
• pas un volume de transactions gigantesques

et gratuit…

Un de mes proches amis (on a fait Orsay ensemble) avait donné dans un ERP PostgreSQL pendant près de 2 ans. Il a du jeter l'éponge faute de client...

Une autre problématique est que PostgreSQL fait peur au TPE/PME parce qu'il n'y a pas d'outil graphique. Quand tu as un seul informaticien dans la boîte, voire même à mi temps… ils préfèrent largement Microsoft SQL Server parce que tout peut être piloté à la clicougnette !

A +

[marc.collin]

Ha oui, le fameux match muscle contre cerveau…
Problème, tu peut toujours rajouter de la RAM ou du processeur. Mais pour une requête ou PostgreSQL est juste 300 000 fois moins performant, tu vas dire à ton boss, achetez moi 300 000 CPU ou 300 000 Go de RAM ???

A +

je lui dirais plutôt je vais prendre 5 minutes pour optimiser la requête