Discussion :

[SQLpro]

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.

ATTENTION : dans certains cas il existe des solutions de contournement, mais elles imposent une restructuration des tables (notamment l'ajout de colonnes) et la récriture des requêtes.
Dans tous les cas, ces solutions ont un coût extrémement important, qui, en pratique pourront être un frein, voir un arrêt de mort concernant un tel projet de portage...

Dans un projet portage on essaye de minimiser l'impact de modification, sinon, le portage risque de coûter plus cher que l'économie que l'on tente de réaliser...

Voici les tests que j'ai mené sur un portable HP doté comme suit :

• CPU Core i7 6500U cadencés à 2,5 Ghz (4 coeurs)
• RAM 32 Go
• Disques SSD

Avant de publier cette série d'article, je vais faire des tests complémentaires sur une machine plus costaude (48 coeurs, 128 Go de RAM, disques SAS et SSD)

* * * * * * *

[T-0050] Test mettant en évidence les contre-performances de PostGreSQL pour des recherches insensibles à la casse

Test pour SQL Server :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
CREATE TABLE T_CASSE (ID      INT IDENTITY PRIMARY KEY,
                      DATUM   VARCHAR(256) COLLATE French_CI_AS);
GO
 
INSERT INTO T_CASSE VALUES ('Paris ! Paris outragé ! Paris brisé ! Paris martyrisé ! Mais Paris libéré !');
GO 7 --> permet de lancer la requête 7 fois
 
INSERT INTO T_CASSE
SELECT T1.DATUM
FROM   T_CASSE AS T1
       CROSS JOIN T_CASSE AS T2;
GO 3 --> permet de lancer la requête 3 fois
 
--> à ce stade nous avons 10 192 056 lignes dans la table
 
INSERT INTO T_CASSE VALUES ('Méli-Mélo');
GO
 
SET STATISTICS TIME ON;
GO
SELECT *
FROM   T_CASSE
WHERE  DATUM = 'méli-mélo';
--> Temps UC = 3109 ms, temps écoulé = 1857 ms.
 
CREATE INDEX X_CASSE ON T_CASSE (DATUM); 
GO
 
SELECT *
FROM   T_CASSE
WHERE  DATUM = 'méli-mélo';
--> Temps UC = 0 ms, temps écoulé = 1 ms.

Sans index la recherche a mis 1 857 ms, avec index 1 ms. SQL Server effectuant une recherche dans l’index.

Test pour PostGreSQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
CREATE TABLE T_CASSE (ID      INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
                      DATUM   VARCHAR(256));
 
INSERT INTO T_CASSE (DATUM) VALUES ('Paris ! Paris outragé ! Paris brisé ! Paris martyrisé ! Mais Paris libéré !');
INSERT INTO T_CASSE (DATUM) VALUES ('Paris ! Paris outragé ! Paris brisé ! Paris martyrisé ! Mais Paris libéré !');
INSERT INTO T_CASSE (DATUM) VALUES ('Paris ! Paris outragé ! Paris brisé ! Paris martyrisé ! Mais Paris libéré !');
INSERT INTO T_CASSE (DATUM) VALUES ('Paris ! Paris outragé ! Paris brisé ! Paris martyrisé ! Mais Paris libéré !');
INSERT INTO T_CASSE (DATUM) VALUES ('Paris ! Paris outragé ! Paris brisé ! Paris martyrisé ! Mais Paris libéré !');
INSERT INTO T_CASSE (DATUM) VALUES ('Paris ! Paris outragé ! Paris brisé ! Paris martyrisé ! Mais Paris libéré !');
INSERT INTO T_CASSE (DATUM) VALUES ('Paris ! Paris outragé ! Paris brisé ! Paris martyrisé ! Mais Paris libéré !');
 
--> lancez 3 fois cette requête :
INSERT INTO T_CASSE (DATUM)
SELECT T1.DATUM
FROM   T_CASSE AS T1
       CROSS JOIN T_CASSE AS T2;
 
--> à ce stade nous avons 10 192 056 lignes dans la table
 
INSERT INTO T_CASSE (DATUM) VALUES ('Méli-Mélo');
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  LOWER(DATUM) = 'méli-mélo';
--> Execution time : 4795.370 ms
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  DATUM ILIKE 'méli-mélo';
--> Execution time : 1541.112 ms
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  DATUM ~ 'méli-mélo';
--> Execution time : 11910.661 ms
 
CREATE INDEX X_CASSE ON T_CASSE (DATUM); 
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  LOWER(DATUM) = 'méli-mélo';
--> Execution time : 5197.753 ms
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  DATUM ILIKE 'méli-mélo';
--> Execution time : 1718.089
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  DATUM ~ 'méli-mélo';
--> Execution time : 10905.050 ms

Sans index, et dans le meilleur des cas PostGreSQL s’en tire un peu mieux que SQL Server grâce à l’opérateur ILIKE, mais sans cet opérateur il est 2,5 fois plus lent. À noter que les plans d’exécution montrent l’emploi du parallélisme avec de 2 threads et systématiquement un parcours séquentiel. Avec un index, le ILIKE est même légèrement moins bon que sans (nous avons réitérer la requête pour être sûr de nous...). Dans tous les cas, avec un index, PostGreSQL est battu à plate couture !

Bilan : SQL Server est 1 718 fois plus rapide que PostGreSQL sur cette recherche insensible à la casse...

* * * * * * *

[T-0060] Test mettant en évidence les contre-performances de PostGreSQL pour des recherches insensibles aux accents et autres caractères diacritiques

Script pour SQL Server :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
CREATE TABLE T_ACCENTS (ID      INT IDENTITY PRIMARY KEY,
                        DATUM   VARCHAR(256) COLLATE French_CS_AI);
GO
 
INSERT INTO T_ACCENTS VALUES ('Écœurée par l’Aÿ Lætitia et son garçon arrivèrent à Paris');
GO 7 --> ceci exécute la requête 7 fois
 
INSERT INTO T_ACCENTS
SELECT T1.DATUM
FROM   T_ACCENTS AS T1
       CROSS JOIN T_ACCENTS AS T2;
GO 3 --> ceci exécute la requête trois fois
 
--> à ce stade nous avons 10 192 056 lignes dans la table
 
INSERT INTO T_ACCENTS VALUES ('méli-mélo');
 
SET STATISTICS TIME ON;
SELECT *
FROM   T_ACCENTS
WHERE  DATUM = 'meli-melo'
--> Temps UC = 3126 ms, temps écoulé = 1805 ms
 
CREATE INDEX X_ACCENTS ON T_ACCENTS (DATUM); 
GO
 
SELECT *
FROM   T_ACCENTS
WHERE  DATUM = 'meli-melo'
--> Temps UC = 0 ms, temps écoulé = 1 ms.

SQL Server a mis 1 805 ms sans index et 1 ms avec index, grâce à la collation.

Script PostGreSQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
CREATE TABLE T_ACCENTS (ID      SERIAL PRIMARY KEY,
                        DATUM   VARCHAR(256));
 
INSERT INTO T_ACCENTS (DATUM) VALUES ('Écœurée par l’Aÿ Lætitia et son garçon arrivèrent à Paris');
INSERT INTO T_ACCENTS (DATUM) VALUES ('Écœurée par l’Aÿ Lætitia et son garçon arrivèrent à Paris');
INSERT INTO T_ACCENTS (DATUM) VALUES ('Écœurée par l’Aÿ Lætitia et son garçon arrivèrent à Paris');
INSERT INTO T_ACCENTS (DATUM) VALUES ('Écœurée par l’Aÿ Lætitia et son garçon arrivèrent à Paris');
INSERT INTO T_ACCENTS (DATUM) VALUES ('Écœurée par l’Aÿ Lætitia et son garçon arrivèrent à Paris');
INSERT INTO T_ACCENTS (DATUM) VALUES ('Écœurée par l’Aÿ Lætitia et son garçon arrivèrent à Paris');
INSERT INTO T_ACCENTS (DATUM) VALUES ('Écœurée par l’Aÿ Lætitia et son garçon arrivèrent à Paris');
 
--> à jouer 3 fois :
INSERT INTO T_ACCENTS (DATUM)
SELECT T1.DATUM
FROM   T_ACCENTS AS T1
       CROSS JOIN T_ACCENTS AS T2;
 
--> à ce stade nous avons 10 192 056 lignes dans la table
 
INSERT INTO T_ACCENTS (DATUM) VALUES ('méli-mélo');
 
--> création de la fonction de désaccentuation :
CREATE OR REPLACE FUNCTION remove_fr_accents(string text) 
RETURNS text 
AS $$
DECLARE out_str text;
BEGIN
   SELECT translate(string, 'âäàÁÂÄèéêëÈÉÊËîïÎÏôöÕÖùûüÙÛÜÿŸÇç', 
                            'aaaAAAeeeeEEEEiiIIooOOuuuUUUyYCc')
          INTO out_str;
   SELECT replace(out_str, 'Œ', 'OE') INTO out_str;
   SELECT replace(out_str, 'Æ', 'AE') INTO out_str;
   SELECT replace(out_str, 'æ', 'ae') INTO out_str;
   SELECT replace(out_str, 'œ', 'oe') INTO out_str;
   RETURN out_str;
END;
$$ LANGUAGE plpgsql;
 
EXPLAIN ANALYZE
SELECT *
FROM   T_ACCENTS
WHERE  remove_fr_accents(DATUM) = 'meli-melo';
--> 331 666 ms
 
CREATE INDEX X_ACCENTS ON T_ACCENTS (DATUM);
 
EXPLAIN ANALYZE
SELECT *
FROM   T_ACCENTS
WHERE  remove_fr_accents(DATUM) = 'meli-melo';
--> 284 990 ms

Bilan : SQL Server est en moyenne 300 000 fois plus rapide que PostGreSQL sur cette recherche insensible aux accents...

Comme la plupart du temps, les bases Microsoft SQL Server sont créées avec une collation sensible aux caractères diacritiques, nous allons maintenant procéder à un nouveau test. La table sera créée avec une collation sensible à la casse et nous allons utiliser l’opérateur COLLATE, pour retrouver notre information...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CREATE TABLE T_ACCENTS2 (ID      INT IDENTITY PRIMARY KEY,
                         DATUM   VARCHAR(256) COLLATE French_CI_AS);
GO
 
INSERT INTO T_ACCENTS2 VALUES ('Écœurée par l’Aÿ Lætitia et son garçon arrivèrent à Paris');
GO 7 --> ceci exécute la requête 7 fois
 
INSERT INTO T_ACCENTS2
SELECT T1.DATUM
FROM   T_ACCENTS2 AS T1
       CROSS JOIN T_ACCENTS2 AS T2;
GO 3 --> ceci exécute la requête trois fois
 
--> à ce stade nous avons 10 192 056 lignes dans la table
 
SELECT COUNT(*) FROM T_ACCENTS2
 
INSERT INTO T_ACCENTS2 VALUES ('méli-mélo');
 
SET STATISTICS TIME ON;
SELECT *
FROM   T_ACCENTS2
WHERE  DATUM COLLATE French_CI_AI = 'meli-melo'
--> Temps UC = 0 ms, temps écoulé = 1 ms

Aussi surprenant que cela puisse paraître SQL Server a mis 1 ms pour retrouver l’information sans que la table soit indexée !

Bilan : une nouvelle fois SQL Server est 300 000 fois plus rapide que PostGreSQL sur cette recherche insensible aux accents et sans faire usage d’index dans SQL Server !...

* * * * * *

Si quelqu'un à des idées pour améliorer les performances de PostgreSQL je suis preneur. Bien entendu pour le second test on peut utiliser le module unaccent, mais cela modifie la structure de la table et oblige de réécrire les requêtes…

A +

[Sodium]

Alors d'abord je n'ai pas dit que je voulais voir tes tests, j'ai dit que je n'avais aucune confiance en tes compétences et ton impartialité et que je voulais voir des benchmarks de tierces personnes.

Ensuite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE INDEX X_CASSE_2 ON T_CASSE (lower(DATUM) varchar_pattern_ops)
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  LOWER(DATUM) = 'méli-mélo';
 
Execution time: 0.058 ms

Ca m'a pris deux minutes pour trouver cette réponse. Tu te prétends expert et tu n'as même pas pris deux minutes pour vérifier s'il n'existait pas des optimisations propres au SGBD que tu veux démolir avant d'effectuer des benchmarks.

Bref, tu es hautain, incroyablement imbu de ta personne et, comme je le soupçonnais, incompétent.

[Sodium]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE INDEX X_CASSE_2 ON T_CASSE (lower(DATUM) varchar_pattern_ops)
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  LOWER(DATUM) = 'méli-mélo';
 
Execution time: 0.058 ms

De rien.

[MaitrePylos]

En fait, les bench de ce genre servent à quoi ?


Pourquoi ajouter un fonction de lower à la requête de Postgres ?


Sur mon serveur 4 gb ssd 4 coeur Linux

la requête suivante (sans lower donc sur Postgres)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  DATUM = 'méli-mélo';

Execution time: 819.848 ms

Avec index

Un peux plus rapide

Execution time: 806.405 ms


Ca prouve pas grand chose.

[Sodium]

Parce que la recherche Postgres est sensible à la casse. Sauf que quand on a trois grammes de bon sens, on adapte son implémentation aux spécificités du langage ou système, on ne lance pas une méthode de bourrin pour ensuite venir hurler "Vous avez vu xy c'est trop nullllllllll, regardez comme je suis intelligent d'avoir mis ça en évidence (rire narquois rappelant un croisement entre un rat et un corbeau)".

[SQLpro]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE INDEX X_CASSE_2 ON T_CASSE (lower(DATUM) varchar_pattern_ops)
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  LOWER(DATUM) = 'méli-mélo';
 
Execution time: 0.058 ms

De rien.

Votre test est totalement hors sujet car il dérive des conditions initiales qui imposent de ne pas réécrire la requête. Visiblement vous ne savez pas lire… Donc je me répète :
"
ATTENTION : dans certains cas il existe des solutions de contournement, mais elles imposent une restructuration des tables (notamment l'ajout de colonnes) et la récriture des requêtes.
Dans tous les cas, ces solutions ont un coût extrêmement important, qui, en pratique pourront être un frein, voir un arrêt de mort concernant un tel projet de portage…
"
Quand on fait un portage on essaye de ne récrire aucun requête…

A +

[SQLpro]

Alors d'abord je n'ai pas dit que je voulais voir tes tests, j'ai dit que je n'avais aucune confiance en tes compétences et ton impartialité et que je voulais voir des benchmarks de tierces personnes.

Ensuite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE INDEX X_CASSE_2 ON T_CASSE (lower(DATUM) varchar_pattern_ops)
 
EXPLAIN ANALYZE
SELECT *
FROM   T_CASSE
WHERE  LOWER(DATUM) = 'méli-mélo';
 
Execution time: 0.058 ms

Ca m'a pris deux minutes pour trouver cette réponse. Tu te prétends expert et tu n'as même pas pris deux minutes pour vérifier s'il n'existait pas des optimisations propres au SGBD que tu veux démolir avant d'effectuer des benchmarks.

Bref, tu es hautain, incroyablement imbu de ta personne et, comme je le soupçonnais, incompétent.

Outre les insultes imbéciles dont vous êtes coutumières, vous prouvez que vous ne savez en plus pas lire !

En effet votre test est totalement hors sujet car il dérive des conditions initiales qui imposent de ne pas réécrire la requête... Donc je me répète :
"
ATTENTION : dans certains cas il existe des solutions de contournement, mais elles imposent une restructuration des tables (notamment l'ajout de colonnes) et la récriture des requêtes.
Dans tous les cas, ces solutions ont un coût extrêmement important, qui, en pratique pourront être un frein, voir un arrêt de mort concernant un tel projet de portage…
"
A lire et relire :
https://www.developpez.net/forums/d2.../#post11357084

Quand on fait un portage on essaye de ne récrire aucun requête… Or votre solution impose une récriture de la requête…

En sus, j'avais mentionné :
"Merci de poster vos remarques dans cette nouvelle enfilade afin d'éviter de polluer l'enfilade présente pour ne pas faire trop dériver le sujet initial."
A lire et à relire :
https://www.developpez.net/forums/d2.../#post11357170
Visiblement soit :

• tu ne sait toujours pas lire ou bien tu as de la merde dans les yeux...
• tu n'en as rien à foutre de polluer les forums

Et peut être même les deux !

A +

[Invité]

Cet "article" est d'une malhonnêteté incroyable :
- Déjà ces 2 requêtes ne sont pas particulièrement représentatives d'une utilisation "classique" d'un SGBD.
- Ensuite, vouloir faire une migration sans adapter le résultat, ce n'est pas sérieux. Je pensais que tout le monde avait arrété ces mauvaises pratiques depuis qu'elles avaient mené à l'explosion d'ariane 5 dans les années 90 mais apparemment non...
- Vous ne justifiez pas que retoucher quelques requêtes mène forcément à un "coût extrémement important".
- Par contre vous répétez au moins 4 fois que les performances de Postgresql sont lamentables.
- 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.

Bref l'article aurait pu être intéressant si vous aviez présenté les dangers de la migration automatique et présenté les bonnes pratiques à suivre. Mais là on a juste l'impression de subir du lobbying maladroit de la part de MS.

[marc.collin]

comme tu dis on essaye de ne pas réécrire.... or les bd n'ont pas tous les mêmes fonctionnalités, ne respecte pas les mêmes révisions du langage sql
à moins d'avoir que des requêtes plus que simple, passer d'un serveur sql à un autre impliquera de modifier des requêtes

il y a plus que probablement le cas inverse, où une requête donne d'excellent résultat sous pg et où la même requête sous oracle, ms sql server donne des résultats moyen

ça serait bien de respecter les gens si tu veux qu'ils te respectent.... cesser de la ramener serait aussi bien... c'est assez récurent dans ton cas et je ne suis pas la première personne à te le faire remarquer.... c'est lassant pour une personne qui répète sans cesse qu'elle est pro...

[Sodium]

Quand on fait un portage on essaye de ne récrire aucun requête… Or votre solution impose une récriture de la requête…

• tu ne sait toujours pas lire ou bien tu as de la merde dans les yeux...
• tu n'en as rien à foutre de polluer les forums

Et peut être même les deux !

A +

1) Je n'ai pas réécris la requête, j'ai ajouté un index
2) L'article s'intitule "Performances comparatives PostGreSQL vs SQL Server", pas "Performances comparatives PostgresSQL vs SQL Server sur un code optimisé pour SQL Server" ?
3) Du coup la comparaison est encore plus ridicule que ce que je pensais. Le but de l'article c'est de prouver que Postgres est moins performant que SQL Server avec du code écrit spécifiquement pour SQL Server ? Et c'est censé... démontrer l'infériorité intrinsèque de Postgres ?

Bref, tu nous rabâches depuis des pages et des pages que SQL Server est 300 000 fois plus performant que Postgres sans préciser de contextes. Je pense tout simplement que tu t'es rendu compte que tu as écrit n'importe quoi et ta réponse n'est qu'une tentative de sauver les meubles.

[Sodium]

Tout est dit. Ton "benchmark" démontre que SQL Server est plus performant que Postgres sur du code pensé pour SQL Server. Bravo, félicitations, tu peux rajouter une ligne de plus à ta signature.

[StringBuilder]

comme tu dis on essaye de ne pas réécrire.... or les bd n'ont pas tous les mêmes fonctionnalités, ne respecte pas les mêmes révisions du langage sql
à moins d'avoir que des requêtes plus que simple, passer d'un serveur sql à un autre impliquera de modifier des requêtes

Réécrire pour porter d'un SGBD a un coût.
Ainsi, s'il faut 200 jours de dev pour porter un produit qui fonctionne correctement sous SQL Server vers PostgreSQL, alors le gain est nul, voir négatif.
Donc l'objectif, lors d'un portage, c'est de toucher un minimum de code.

1) Je n'ai pas réécris la requête, j'ai ajouté un index

Il ne me semble pas avoir vu passer un "lower()" dans la requête d'origine. Donc si, outre un index, il y a bien eu une modification du code SQL.
Sur un cas aussi trivial, le coût est quasi nul. S'il y a des milliers de requêtes, dynamiques tant qu'à faire, ou générées par un ORM par exemple, ça va devenir beaucoup moins simple à faire.

Mais surtout, outre le coût de réécriture de ces requête, le risque se situe dans les régressions potentielles : que se passe-t-il si on oublie de modifier une requête ? Si au contraire, on en modifie une qu'on n'aurait pas dû ? On ne va pas simplement avoir des performances dégradées, mais avant tout un comportement différent, donc un bug.

Pour info, SQL Server permet d'utiliser différentes collations qui permettent, entre autre, de choisir de considérer comme identiques ou différentes les lettres accentuées ou majuscule. PostgreSQL ne le permet visiblement pas, et le script de SQLPro est là pour démontrer que c'est problématique si on en a besoin (dans une application existante).

Pour les deux autres points de on post, le contexte de la comparaison a bien été donné : il s'agit de comparer un code écrit sur SQL Server si on le transpose sous PostgreSQL.
Comme tu dis, un teste dans l'autre sens serait probablement le bienvenu, mais j'ai quelques doutes qu'on tombe sur des choses aussi flagrandes, puisque SQL Server propose en règle générale une meilleure couverture du standard SQL et implémente plus de fonctionnalités (il me semble qu'il y a quelques versions, PG était plus rapide sur des requêtes spatiales, je ne sais pas si Microsoft a comblé cette lacune depuis).

[Sodium]

Réécrire pour porter d'un SGBD a un coût.
Ainsi, s'il faut 200 jours de dev pour porter un produit qui fonctionne correctement sous SQL Server vers PostgreSQL, alors le gain est nul, voir négatif.
Donc l'objectif, lors d'un portage, c'est de toucher un minimum de code.

Si tu veux faire un portage sans toucher au code, ne fais pas de portage... ou encore confie ça à une personne dont le but de la vie n'est pas de rester planquée 20 ans en refusant catégoriquement de s'intéresser à autre chose que sa compétence de base.

Il ne me semble pas avoir vu passer un "lower()" dans la requête d'origine. Donc si, outre un index, il y a bien eu une modification du code SQL.

Il te semble mal, la requête est identique, ligne 42 de son deuxième bloc de code... C'est SQLAmateur qui a rajouté le LOWER par rapport à la requête SQL Server.

Mais surtout, outre le coût de réécriture de ces requête, le risque se situe dans les régressions potentielles : que se passe-t-il si on oublie de modifier une requête ? Si au contraire, on en modifie une qu'on n'aurait pas dû ? On ne va pas simplement avoir des performances dégradées, mais avant tout un comportement différent, donc un bug.

Encore une fois, si on ne veut pas effectuer de travail d'adaptation, on ne change pas de SGBD sur un projet.

Pour info, SQL Server permet d'utiliser différentes collations qui permettent, entre autre, de choisir de considérer comme identiques ou différentes les lettres accentuées ou majuscule. PostgreSQL ne le permet visiblement pas, et le script de SQLPro est là pour démontrer que c'est problématique si on en a besoin (dans une application existante).

Je n'ai pas les réponses à ces éléments car je n'en ai pas les compétences. Par contre, je vais partir du principe raisonnable que les devs de Postgres ne sont pas complètement stupides et qu'il y a une logique derrière ce choix. Si l'on est trop paresseux pour s'intéresser aux spécificités d'un autre système que celui auquel l'on est habitué et que l'on refuse de chercher des solutions, on ne se prétend pas expert.

Pour les deux autres points de on post, le contexte de la comparaison a bien été donné : il s'agit de comparer un code écrit sur SQL Server si on le transpose sous PostgreSQL.

Relis le titre : Performances comparatives PostGreSQL vs SQL Server

Je vais être gentille et ne pas affirmer qu'il s'agit sciemment d'une tentative d'induire en erreur les lecteurs. C'est comme si j'intitulais un article "La Twingo voiture la plus rapide du monde" et que j'écrivais quelque part en petit dans le contenu "en lui attachant un moteur de lanceur extra-orbital".

[SQLpro]

...
ça serait bien de respecter les gens si tu veux qu'ils te respectent.... cesser de la ramener serait aussi bien... c'est assez récurent dans ton cas et je ne suis pas la première personne à te le faire remarquer.... c'est lassant pour une personne qui répète sans cesse qu'elle est pro...

J'ai l'impression d'être pris pour un con par des intégristes illuminés !

En effet, j'ai bien précisé le contexte :
"Portage de base SQL Server vers PostGreSQL"
Il s'agit donc de se poser la question suivante : quelle problématique vais-je rencontrer si je passe de SQL Server à PostGreSQL... et non l'inverse.
Comme vous êtes intelligent, je vous laisse le soin d'écrire l'article inverse :
"Portage de base de données de PostGreSQL à SQL Server", afin de nous démonter les fabuleux gains de performances et la supériorité de PostGreSQL.

A +

[SQLpro]

...il me semble qu'il y a quelques versions, PG était plus rapide sur des requêtes spatiales, je ne sais pas si Microsoft a comblé cette lacune depuis).

C'est l'inverse... PostGreSQL est bien moins rapide sur le spatial que SQL Server :
https://g-ernaelsten.developpez.com/...-performances/

A +

[Sodium]

J'ai l'impression d'être pris pour un con par des intégristes illuminés !

Pour le premier point j’acquiesce avec plaisir. Pour ce qui est d'être intégriste, c'est toi qui nous scande la toute puissance de SQL Server alors que tu ne connais pas la concurrence. Quant à illuminé, quand on sort des absurdités telles que "Machin est 300 000 fois plus puissant que truc", je pense qu'on peut dire ça.

En effet, j'ai bien précisé le contexte :

Ton titre est totalement non pertinent, le développement porte à confusion, ta conclusion laisse entendre que ces différences de performances sont globaux dans Postgres.

Le minimum d'honnêteté aurait été de montrer qu'avec un le simple ajout d'un index on arrive aux mêmes résultats, quitte à expliquer ensuite pourquoi tu ne conserves pas cette solution. Mais non, ta conclusion c'est "Postgres c'est nul" et c'est marre.

Bref, un torchon que je n'accepterais pas d'un étudiant en première année.

Comme vous êtes intelligent, je vous laisse le soin d'écrire l'article inverse :
"Portage de base de données de PostGreSQL à SQL Server", afin de nous démonter les fabuleux gains de performances et la supériorité de PostGreSQL.

Honnêtement, j'ai autre chose à faire de mes journées que de rechercher un substitut phallique dans des SGBD. Si tu utilisais tout ce temps pour te former, ce que tu as à dire en deviendrait peut-être plus intéressant.

C'est l'inverse... PostGreSQL est bien moins rapide sur le spatial que SQL Server :
https://g-ernaelsten.developpez.com/...-performances/

A +

C'est pas faute de l'avoir répété, mais encore une fois on ne remporte pas un débat en postant ses propres sources, encore moins sans un minimum de pair review. Selon les écrits de Benveniste, l'homéopathie ça marche

[SQLpro]

...

Relis le titre : Performances comparatives PostGreSQL vs SQL Server

Je vais être gentille et ne pas affirmer qu'il s'agit sciemment d'une tentative d'induire en erreur les lecteurs. C'est comme si j'intitulais un article "La Twingo voiture la plus rapide du monde" et que j'écrivais quelque part en petit dans le contenu "en lui attachant un moteur de lanceur extra-orbital".

Encore une fois vous tronquez mes propos pour affirmer vos balivernes…. Votre mauvaise foi est constante...

J'ai précisé le contexte du portage de SQL Server à PostgreSQL cela à mainte reprises, exemple ici :
https://www.developpez.net/forums/d2.../#post11342367
Je me cite (extrait) :
"Pour information, je suis en train d'écrire un long article sur le portage de MS SQL Server vers PostgreSQL avec de nombreux tests de performances….

A -

[Sodium]

Pour un développeur compétent, "porter" d'une techno à une autre sous-tend que l'on va adapter un minimum le code pour avoir des fonctionnalités et performances équivalentes, je suis désolée pour toi que tu ne fasses pas partie de cette catégorie de personnes

"Oalala j'ai copié le binaire de mon application MacOS sur Windows 10 et elle démarre pas, bouh c'est trop nul Windows !"

[esperanto]

L'accès à un index peut donc se faire de deux manières :

• En mode recherche (on appelle cela un "seek") et dans ce cas il y a utilisation de l'arbre de recherche. Ceci suppose que le prédicat de recherche est "sargable" (cherchable).
• En mode séquentiel (on apelle cela un "scan" - balayage) et dans ce cas, l'accès est exactement le même que dans une table non indexée… C'est le cas lorsque le prédicat de n'est pas cherchable.

Après vérification, non, un index scan n'est pas équivalent à un table scan. Comme je le supposais, et j'ai obtenu la confirmation ici, dès lors qu'on fait une requête avec un intervalle, on ne peut pas se contenter d'un seek mais on peut procéder comme ceci:
1. parcourir le B-Tree pour rechercher la première borne (inférieure) de l'intervalle
2. faire un balayage (scan) mais uniquement à partir de l'entrée trouvée au point 1,
3. arrêter le balayage dès qu'on est au delà de la deuxième borne (supérieure) de l'intervalle, puisque par définition, l'index est trié
Donc il y a bien un balayage de l'index mais partiel (sinon ce serait un Index FULL Scan). C'est surtout pour ça qu'il est plus rapide que le balayage de la table (différence entre la requête 1 et 2)

Maintenant si tu connais assez "intimement" le fonctionnement de PostgreSQL pour dire que ce qui est écrit dans mon lien est faux, tu peux toujours me donner une référence à l'intérieur du code source de PostgreSQL...

J'attends donc toujours de voir à quel type de requête un index couvrant toutes les colonnes d'une table, ou tous les champs d'une colonne XML, est mieux adapté qu'un index ne couvrant que certains champs

La démonstration vous a été donné ici. Commencez par apprendre à lire !
https://www.developpez.net/forums/d2.../#post11349241

Si c'est le cas alors tu a l'art de la contradiction! En gros le message que tu cites montre bien que pour qu'un index à plusieurs colonnes soit utilisable, la requête doit respecter des conditions très particulières, telles que d'impliquer au moins la première colonne de l'index, puis la deuxième, etc. Mais ensuite, tu trouves super efficace d'indexer toutes les colonnes dans un seul index, comme s'il était plus courant d'écrire des requêtes impliquant toutes les colonnes dans le WHERE que des requêtes où le WHERE n'en utilise qu'une ou deux!
A moins bien sûr que les index de type "CLUSTERED COLUMNSTORE INDEX" utilisent une autre technique que le B-Tree qui ne soit pas affectée par les limitations que tu cites toi-même dans ton message: mais alors la question de savoir à quelles requêtes il s'applique redevient pertinente.

Quant à faire la même chose pour du XML, alors laisse-moi rire: s'il faut que toutes les requêtes impliquent les premiers champs du document XML, alors autant dire que l'index ne marchera que pour 0.01% des requêtes.

[SQLpro]

Après vérification, non, un index scan n'est pas équivalent à un table scan. Comme je le supposais, et j'ai obtenu la confirmation ici, ...

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...
Et comme la petite mention sous le titre l'indique "Table des matières › Plans d'exécution › PostgreSQL › " c'est spécifique à PostgreSQL….
Je vous invite à lire des études sérieuses écrite par des chercheurs et non des logorrhées de bidouilleurs. Exemple :
https://ijcsmc.com/docs/papers/Decem...7I12201845.pdf
https://research.cs.wisc.edu/niagara/papers/ZND+01.pdf
D'ailleurs l'auteur se réfère souvent à PostGreSQL, seul SGBD qu'il semble connaître !

A moins bien sûr que les index de type "CLUSTERED COLUMNSTORE INDEX" utilisent une autre technique que le B-Tree qui ne soit pas affectée par les limitations que tu cites toi-même dans ton message: mais alors la question de savoir à quelles requêtes il s'applique redevient pertinente.

Exactement, c'est que que j'ai dit à mainte reprise. L'index columstore n'utilise par un B-Tree, mais un rangement vertical, chaque colonne étant indexée séparément avec une technique de hachage et de compression…
Les méthodes utilisées par les index "verticaux" (d'où le nom columstore) sont décrites notamment dans le papier de recherche suivante :
http://db.csail.mit.edu/pubs/abadi-column-stores.pdf

Quant à faire la même chose pour du XML, alors laisse-moi rire: s'il faut que toutes les requêtes impliquent les premiers champs du document XML, alors autant dire que l'index ne marchera que pour 0.01% des requêtes.

Quand à votre incrédulité sur le sujet, vous pouvez lire le papier de MS Research qui indique comment sont fait les index XML dans MS SQL Server :
https://www.immagic.com/eLibrary/ARC...T/M040611P.pdf
et notamment le § 4. Experimental Results using XMark Benchmark
Vous verrez alors que sur les 20 requêtes du benchmark il n'y a que 2 cas ou l'index est inefficace. Ce n'est dont pas 0,01% des cas comme vous l'affirmez si stupidement, mais 80 % des cas ou l'indexation XML de Microsoft SQL Server est plus ou moins efficace !...

Sur ces deux sujets : indexation du XML et indexation verticale, PostgreSQL en est à des années lumières…
Pour l'indexation verticale : https://wiki.postgresql.org/wiki/Fut...lumnar_indexes
Pour le XML en général :
https://wiki.postgresql.org/wiki/Pos.../XML_Standards
https://www.postgresql.org/docs/12/x...nformance.html
https://www.postgresql.org/docs/11/u...-standard.html


A +