Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Décisions SGBD Discussion :

Performances comparatives PostGreSQL vs SQL Server


Sujet :

Décisions SGBD

  1. #1
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    19 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 546
    Points : 46 245
    Points
    46 245
    Par défaut Performances comparatives PostGreSQL vs SQL Server
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  2. #2
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 964
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 964
    Points : 1 950
    Points
    1 950
    Billets dans le blog
    1
    Par défaut
    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.

  3. #3
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 964
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 964
    Points : 1 950
    Points
    1 950
    Billets dans le blog
    1
    Par défaut
    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.

  4. #4
    Modérateur

    Avatar de MaitrePylos
    Homme Profil pro
    DBA
    Inscrit en
    juin 2005
    Messages
    5 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA
    Secteur : Service public

    Informations forums :
    Inscription : juin 2005
    Messages : 5 198
    Points : 11 744
    Points
    11 744
    Par défaut
    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.

  5. #5
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 964
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 964
    Points : 1 950
    Points
    1 950
    Billets dans le blog
    1
    Par défaut
    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)".

  6. #6
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    19 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 546
    Points : 46 245
    Points
    46 245
    Par défaut
    Citation Envoyé par Sodium Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  7. #7
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    19 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 546
    Points : 46 245
    Points
    46 245
    Par défaut
    Citation Envoyé par Sodium Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  8. #8
    Expert confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    919
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 919
    Points : 4 011
    Points
    4 011
    Par défaut
    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.

  9. #9
    Membre éprouvé
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    juin 2012
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juin 2012
    Messages : 448
    Points : 1 006
    Points
    1 006
    Par défaut
    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...
    Aillez le courage de justifier vos -1.
    http://www.laboiteaprog.com/ - http://www.solutions-norenda.com/

  10. #10
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 964
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 964
    Points : 1 950
    Points
    1 950
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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.

  11. #11
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 964
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 964
    Points : 1 950
    Points
    1 950
    Billets dans le blog
    1
    Par défaut
    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.

  12. #12
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 784
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 784
    Points : 6 671
    Points
    6 671
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par marc.collin Voir le message
    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.

    Citation Envoyé par Sodium Voir le message
    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).
    On ne jouit bien que de ce qu’on partage.

  13. #13
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 964
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 964
    Points : 1 950
    Points
    1 950
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    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.

    Citation Envoyé par StringBuilder Voir le message
    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.

    Citation Envoyé par StringBuilder Voir le message
    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.

    Citation Envoyé par StringBuilder Voir le message
    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.

    Citation Envoyé par StringBuilder Voir le message
    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".

  14. #14
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    19 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 546
    Points : 46 245
    Points
    46 245
    Par défaut
    Citation Envoyé par marc.collin Voir le message
    ...
    ç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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  15. #15
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    19 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 546
    Points : 46 245
    Points
    46 245
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    ...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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  16. #16
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 964
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 964
    Points : 1 950
    Points
    1 950
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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.

    Citation Envoyé par SQLpro Voir le message
    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.

    Citation Envoyé par SQLpro Voir le message
    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.

    Citation Envoyé par SQLpro Voir le message
    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

  17. #17
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    19 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 546
    Points : 46 245
    Points
    46 245
    Par défaut
    Citation Envoyé par Sodium Voir le message
    ...

    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 -
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  18. #18
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    1 964
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 964
    Points : 1 950
    Points
    1 950
    Billets dans le blog
    1
    Par défaut
    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 !"

  19. #19
    Membre expérimenté
    Inscrit en
    janvier 2006
    Messages
    432
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 432
    Points : 1 348
    Points
    1 348
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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...

    Citation Envoyé par SQLpro Voir le message
    Citation Envoyé par esperanto Voir le message
    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.

  20. #20
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    19 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 546
    Points : 46 245
    Points
    46 245
    Par défaut
    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 !

    Citation Envoyé par esperanto Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

Discussions similaires

  1. Performances temps d'insertions sql server
    Par KRis dans le forum Bases de données
    Réponses: 5
    Dernier message: 24/04/2008, 20h17
  2. Migration de PostGreSQL vers SQL Server
    Par Jidoche dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 01/08/2007, 19h37
  3. Migration PostGreSql vers SQL Server
    Par ZeMomoDesBois dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 09/11/2006, 08h43
  4. Outil pour comparer des bases SQL Server 2000
    Par plutonium719 dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 22/08/2006, 08h54
  5. Postgresql vs SQL Server
    Par tanys dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 15/01/2005, 16h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo