Comparaison des performances de SIG

Station de travail HP Z840 avec :

• 8 disques SAS de 1.2 To 10 K RPM organisé en un agrégat RAID 10 (unités C et D) ;
• 2 CPU Intel Xeon E5-2680 v3 - 2.5 Ghz - 12 cœurs, hyperthreadés ;
• 128 Go de RAM.

OS Windows 10 version Enterprise.

Les versions que nous avons utilisées sont les suivantes :

• PostgreSQL 9.6.1, compiled by Visual C++ build 1800, 64-bit (pour Windows) ;
• Microsoft SQL Server 2016 (SP1-GDR) (KB3207512) - 13.0.4199.0 (X64) Nov 18 2016 15:56:54 Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows 10 Enterprise 6.3 <X64> (Build 14393: ).

Les deux SGBDR peuvent être téléchargés gratuitement :

PostGreSQL : https://www.postgresql.org/download/.

Pour Windows, utilisez l'installeur de EnterpriseDB et « Stack Builder » pour ajouter la cartouche spatiale PostGIS.

La version SQL Server 2016 SP1 Developer est gratuite, mais ne peut pas servir en production :

https://www.microsoft.com/en-us/sql-server/sql-server-editions-developers.

L'outil client (SSMS : SQL Server management Studio) doit être téléchargé séparément :

https://msdn.microsoft.com/library/mt238290.aspx.

Les installations des deux SGBDR sont standard. Aucun réglage particulier n'a été mis en œuvre au niveau des serveurs.

GEOFLA : https://www.data.gouv.fr/fr/datasets/geofla-r/.

ROUTE 500 IGN : http://professionnels.ign.fr/route500.

Une table de correspondance codes postaux/code INSEE communes, disponible sur le site du gouvernement à l'URL :

https://www.data.gouv.fr/fr/datasets/correspondance-entre-les-codes-postaux-et-codes-insee-des-communes-francaises/.

Pour PostGreSQL, nous avons créé une base de données de nom DB_GEO d'après le template PostGIS. Ceci rajoute quelques objets de métadonnées spécifiques au spatial.

Pour alimenter la base, nous avons utilisé l'outil « PostGIS Shapefile Import/Export Manager », avec le paramétrage standard (voir figure 2).

Nous avons chargé les données en utilisant le format shapefile et l'utilitaire s'est avéré assez rapide pour l'import (une minute trente pour l'ensemble des fichiers).

Finalement, les tables sont constituées des colonnes présentes dans le fichier, auquel est rajouté :

• une colonne de nom gid type INTEGER constituant la clef primaire de la table (avec un index BTree) ;
• un index spatial de type GIST sur la colonne contenant la géométrie.

La base fait 807 Mo.

Pour SQL Server, nous avons créé une base de nom DB_GEO en mode de récupération simple afin d'éviter une journalisation continue et sans purge des transactions.

Nous avons utilisé l'outil FME pour l'import.

Nous y avons rajouté les mêmes clefs primaires et index spatiaux, comme suit :

ALTER TABLE nom_table ADD GID INT IDENTITY PRIMARY KEY;
CREATE SPATIAL INDEX nom_index
       ON nom_table (GEOM)
       WITH ( BOUNDING_BOX = (x_min, y_min, x_max, y_max) );

SQL Server nécessite que les colonnes de type geometry aient un SRID de 0. Pour ceci nous avons modifié par UPDATE, tous les SRID de toutes les colonnes, comme suit :

UPDATE nom_table SET colonne_geometry.STSrid = 0;

Voir annexe 1 : ajout des clefs primaires et index spatiaux et modification des SRID.

La base fait 1 030 Mo.

Nous avons fait en sorte que les services de chaque moteur soient à l'arrêt pendant que l'autre était testé.

Chaque requête a été lancée une fois pour obtenir la mise en cache des données puis dix fois de suite. Les valeurs extrêmes minimales et maximales ont été supprimées du jeu, puis une moyenne a été établie sur les huit résultats restants.

Pour recueillir les métriques, nous avons utilisé les commandes suivantes afin d'obtenir les temps d'exécution :

• PostGreSQL : EXPLAIN ANALYZE ;
• SQL Server : SET NOCOUNT ON; SET STATISTICS TIME ON;.

Les outils utilisés sont ceux livrés en standard, à savoir :

• PostGreSQL : pgAdmin 4 (version 1.1) ;
• SQL Server : SSMS (SQL Server Management Studio - version 13.0.16100.1).

SQL Server et PostGIS/PostGreSQL sont à même niveau et conforme à l'OGC. Il existe cependant quelques petites différences…

Forme des fonctions spatiales

Le standard OGC et la partie spatiale de la norme SQL (ISO/IEC 13249-3:2016, Part 3 : spatial) propose des fonctions scalaires ayant la forme suivante : ST_nomFonction, par exemple ST_PointOnSurface, ST_Touches, ST_StartPoint.

PostGreSQL s'y plie, mais rajoute des fonctions en dehors du scope de l'OGC/norme SQL avec la même forme, ce qui entretient une certaine confusion et pose des problèmes pour les fonctions standardisées à venir.

SQL Server est proche du motif OGC/norme SQL à deux détails près :

• pas de blanc souligné après le ST ;
• méthode appliquée à un objet et non pas fonction scalaire (donc syntaxe différente)

Pour ce qui concerne les méthodes en dehors du scope OGC, SQL Server ne met pas de ST devant. Exemple : MakeValid (tandis que pour PostGreSQL, c'est ST_MakeValid qui n'existe pas, ni dans le standard OGC, ni dans la norme SQL).

Booléen

Dans PostGreSQL, les fonctions renvoyant un booléen renvoient true ou false, mais les fonctions PostGIS ne peuvent être utilisées directement comme expression logique d'un prédicat.

Dans SQL Server, elles renvoient 0 ou 1, et, de même, ne peuvent être utilisées directement comme expression logique d'un prédicat.

Concaténation

Elle s'opère avec + dans SQL Server et || dans postGreSQL. Cependant, tous deux acceptent la fonction CONCAT.

Nous nous sommes cantonné aux fonctions principales et standardisées du spatial (OGC) avec parfois une jointure spatiale et des agrégats (spatiaux et scalaires).

La plupart des requêtes que nous avons élaborées résultent de la réalité d'exploitation des bases spatiales à un niveau basique.

Nous aurions pu élaborer des requêtes spatiales beaucoup plus complexes et spécifiques, mais les comparaisons auraient été faussées du fait des fonctions spécifiques en plus d'être peu représentatives.

N'hésitez pas à nous fournir de nouvelles requêtes spatiales de test, mais à condition qu'elles suivent le standard OGC ou que les fonctions spécifiques y figurant soient très largement utilisées.

Lorsque nous aurons de nouveau un panel intéressant de requêtes, nous produirons les résultats d'un nouveau test.

La communauté PostGreSQL est habituée à nous affirmer que le test est faussé en défaveur de PostGreSQL du fait de l'utilisation de Windows et non pas Linux, arguant que sous Linux, les performances sont nettement meilleures. Nous n'avons jamais remarqué cela en production, mais certaines choses tournent un peu plus vite et d'autres un peu moins… Et tout cela à la marge !

Comme SQL Server sortira sous Linux dans quelques mois, nous publierons un comparatif sur cette plateforme pour les deux SGBDR. Nous aurons alors un test complet permettant de comparer à la fois les plateformes complètes (OS + SGBDR) et de manière croisée.

De toute façon, nous donnons tous les éléments techniques sous forme de fichier de manière à ce que chacun puisse reproduire le test chez lui dans ses propres conditions particulières et en tirer les conclusions qui s'imposeront.

Dans les deux cas, la requête produit les dix résultats suivants :

insee_com   postal_code   nom_comm
----------- ------------- ----------------------
09042       09240         LA BASTIDE-DE-SEROU
02232       02600         COYOLLES
71028       71270         BEAUVERNOIS
68078       68420         EGUISHEIM
05052       05600         EYGLIERS
48080       48300         LANGOGNE
22209       22650         PLOUBALAY
67486       67920         SUNDHOUSE
2B049       20214         CALENZANA
2A272       20100         SARTENE

SELECT *, ST_IsValidDetail(geom)
FROM   s_adr.code_insee_code_postal
WHERE ST_IsValid(geom) = false;

SELECT *, GEOM.IsValidDetailed()
FROM  S_ADR.CODE_INSEE_CODE_POSTAL
WHERE GEOM.STIsValid() = 0

La raison invoquée par postGreSQL est : « Nested shells » et indique une géométrie.

La raison invoquée par SQL Server est : « non valide, car l'anneau (2) est le premier anneau d'un polygone dont il n'est pas l'anneau extérieur. Le problème se produit dans l'entrée (3) d'une collection geometry. »

SQL Server s'avère près de huit fois plus rapide.

Le plan d'exécution de SQL Server ne montre aucun parallélisme. Le plan de PostGreSQL ne montre pas le détail des étapes de calcul.

Dans les deux cas, le résultat est la commune d'Arles.

SELECT *
FROM   S_GEO.COMMUNE
WHERE ST_Area(geom) =
   (SELECT MAX(ST_Area(GEOM))
    FROM   S_GEO.COMMUNE)

SELECT *
FROM  S_GEO.COMMUNE
WHEREGEOM.STArea() =
   (SELECT MAX(GEOM.STArea())
    FROM  S_GEO.COMMUNE)

Temps similaires, léger avantage à PostGreSQL (5,44 %).

Le résultat donne 96 lignes.

SELECT CODE_DEPT, ST_Union(GEOM)
FROM   S_GEO.COMMUNE
GROUP BY CODE_DEPT;

SELECT CODE_DEPT, geometry::UnionAggregate(GEOM)
FROM  S_GEO.COMMUNE
GROUPBY CODE_DEPT;

Le plan d'exécution de SQL Server montre une utilisation massive du parallélisme dans deux séquences différentes. En revanche PostGreSQL n'utilise pas de parallélisme bien qu'il fasse une lecture par balayage de la table (sequential scan).

SQL Server s'avère près de dix fois plus rapide.

Recherches des communes les plus proches de seize points distincts dont dix situés à l'intérieur de communes et six en dehors.

WITH
POINTS AS
(
    SELECT CAST('POINT ( 430354.933 6623007.700)' AS geometry) AS P, 1 AS N
    UNION ALL
    SELECT CAST('POINT ( 980190.133 6333111.233)' AS geometry), 2
    UNION ALL
    SELECT CAST('POINT ( 574865.267 6909297.167)' AS geometry), 3
    UNION ALL
    SELECT CAST('POINT ( 501587.200 6548318.933)' AS geometry), 4
    UNION ALL
    SELECT CAST('POINT ( 444282.067 6251421.667)' AS geometry), 5
    UNION ALL
    SELECT CAST('POINT ( 460953.333 6775817.633)' AS geometry), 6
    UNION ALL
    SELECT CAST('POINT (1032008.400 6323716.133)' AS geometry), 7
    UNION ALL
    SELECT CAST('POINT ( 875328.767 6866887.500)' AS geometry), 8
    UNION ALL
    SELECT CAST('POINT ( 666398.867 6560452.500)' AS geometry), 9
    UNION ALL
    SELECT CAST('POINT ( 354528.400 6636467.900)' AS geometry), 10
    UNION ALL
    SELECT CAST('POINT (1251250.400 6464646.125)' AS geometry), 11
    UNION ALL
    SELECT CAST('POINT ( 315060.950 6874532.888)' AS geometry), 12
    UNION ALL
    SELECT CAST('POINT ( 415263.920 7077070.707)' AS geometry), 13
    UNION ALL
    SELECT CAST('POINT ( 559988.123 6050300.400)' AS geometry), 14
    UNION ALL
    SELECT CAST('POINT ( 334455.250 6333111.200)' AS geometry), 15
    UNION ALL
    SELECT CAST('POINT ( 312459.258 7172737.333)' AS geometry), 16
),
DISTANCES AS
(
    SELECT N, P, ID_GEOFLA, INSEE_COM, NOM_COM, GEOM,
           ST_Distance(P, GEOM) AS D, RANK() OVER(PARTITION BY N ORDER BY ST_Distance(P, GEOM)) AS R
    FROM   S_GEO.COMMUNE
           CROSS JOIN POINTS
)
SELECT *, CASE D WHEN 0 THEN 'intérieur' ELSE 'extérieur' END AS SITUATION
FROM   DISTANCES
WHERE R = 1;

WITH
POINTS AS
(
    SELECT CAST('POINT ( 430354.933 6623007.700)' AS geometry) AS P, 1 AS N
    UNION ALL
    SELECT CAST('POINT ( 980190.133 6333111.233)' AS geometry), 2
    UNION ALL
    SELECT CAST('POINT ( 574865.267 6909297.167)' AS geometry), 3
    UNION ALL
    SELECT CAST('POINT ( 501587.200 6548318.933)' AS geometry), 4
    UNION ALL
    SELECT CAST('POINT ( 444282.067 6251421.667)' AS geometry), 5
    UNION ALL
    SELECT CAST('POINT ( 460953.333 6775817.633)' AS geometry), 6
    UNION ALL
    SELECT CAST('POINT (1032008.400 6323716.133)' AS geometry), 7
    UNION ALL
    SELECT CAST('POINT ( 875328.767 6866887.500)' AS geometry), 8
    UNION ALL
    SELECT CAST('POINT ( 666398.867 6560452.500)' AS geometry), 9
    UNION ALL
    SELECT CAST('POINT ( 354528.400 6636467.900)' AS geometry), 10
    UNION ALL
    SELECT CAST('POINT (1251250.400 6464646.125)' AS geometry), 11
    UNION ALL
    SELECT CAST('POINT ( 315060.950 6874532.888)' AS geometry), 12
    UNION ALL
    SELECT CAST('POINT ( 415263.920 7077070.707)' AS geometry), 13
    UNION ALL
    SELECT CAST('POINT ( 559988.123 6050300.400)' AS geometry), 14
    UNION ALL
    SELECT CAST('POINT ( 334455.250 6333111.200)' AS geometry), 15
    UNION ALL
    SELECT CAST('POINT ( 312459.258 7172737.333)' AS geometry), 16
),
DISTANCES AS
(
    SELECT N, P, ID_GEOFLA, INSEE_COM, NOM_COM, GEOM,
           P.STDistance(GEOM) AS D, RANK() OVER(PARTITION BY N ORDER BY P.STDistance(GEOM)) AS R
    FROM  S_GEO.COMMUNE
           CROSS JOIN POINTS
)
SELECT *, CASE D WHEN 0 THEN 'intérieur' ELSE 'extérieur' END AS SITUATION
FROM  DISTANCES
WHERER = 1;

La requête produit seize résultats identiques. Même les distances sont strictement identiques sur les neuf décimales produites !

Les plans de requête sont très différents et montrent une continuité du parallélisme dans SQL Server.

Avantage à PostGreSQL qui met presque deux fois moins de temps que SQL Server.

Les résultats sont identiques et dans le même ordre :

NOMS                                           GEO
---------------------------------------------- -------------------------------------------
CALVADOS / SEINE-MARITIME                      0x000000000104550E0000CDCCCCCC2BEF2041CD...
YVELINES / PARIS                               0x000000000104830500009A99999970E4234167...
ALPES-DE-HAUTE-PROVENCE / BOUCHES-DU-RHONE     0x000000000104DD0F000034333333C2CC2C4134...
PARIS / VAL-D'OISE                             0x000000000104EA04000000000000F892234100...
HAUTE-SAONE / HAUT-RHIN                        0x000000000104A10C000034333333A2202F4167...
LOIRE-ATLANTIQUE / MAYENNE                     0x000000000104600E000034333333D5031A4134...
VOSGES / MOSELLE                               0x0000000001048D13000000000000EFB32E4134...

SELECT D1.nom_dept || ' / ' || D2.nom_dept AS NOMS, ST_Union(D1.geom, D2.geom) AS GEO
FROM   s_geo.departement AS D1
       JOIN s_geo.departement AS D2
            ON ST_Distance(D1.geom, D2.geom) < 5000
            AND ST_Touches(D1.geom, D2.geom) = false
            AND D1.gid < D2.gid;

SELECT D1.NOM_DEPT + ' / ' + D2.NOM_DEPT AS NOMS, D1.GEOM.STUnion(D2.GEOM) AS GEO
FROM  S_GEO.DEPARTEMENT AS D1
       JOIN S_GEO.DEPARTEMENT AS D2
            ON D1.GEOM.STDistance(D2.GEOM) < 5000
            AND D1.GEOM.STTouches(D2.GEOM) = 0
            AND D1.GID < D2.GID;

Le plan produit par SQL Server est classique et n'effectue aucun parallélisme. Il est pratiquement identique à celui de PostGreSQL.

SQL Server s'avère près de cinq fois plus rapide.

Cette recherche ne doit pas prendre en compte les communes limitrophes, c'est-à-dire celles ayant une frontière commune avec le département de rattachement.

SELECT CODE_COM, NOM_COM, C.CODE_DEPT, C.NOM_DEPT, C.GEOM
FROM   S_GEO.COMMUNE AS C
       JOIN S_GEO.DEPARTEMENT AS D
            ON C.CODE_DEPT = D.CODE_DEPT
            AND ST_Intersects(C.GEOM, ST_Boundary(D.GEOM)) = false
WHERE ST_Area(C.GEOM) > 34567890;

SELECT CODE_COM, NOM_COM, C.CODE_DEPT, C.NOM_DEPT, C.GEOM
FROM  S_GEO.COMMUNE AS C
       JOIN S_GEO.DEPARTEMENT AS D
            ON C.CODE_DEPT = D.CODE_DEPT
            AND C.GEOM.STIntersects(D.GEOM.STBoundary()) = 0
WHERE C.GEOM.STArea() > 34567890;

La réponse contient 1716 lignes, dont les dix premiers et dix derniers résultats sont (figure 14) :

Les plans de requête sont assez similaires :

Cependant, SQL Server nous suggère de créer l'index suivant :

CREATE NONCLUSTERED INDEX XG_COM_CODE_DEPT
   ON S_GEO.COMMUNE (CODE_DEPT)
   INCLUDE (CODE_COM,NOM_COM,NOM_DEPT,GEOM);

Arguant que celui-ci améliorerait de 96 % les performances de la requête… Après de nouveaux tests avec cet index, et alors que le nouveau plan montre bien l'utilisation de cet index, nous pouvons affirmer que cette amélioration n'existe pas, pire, il apparaît que le résultat est légèrement moins bon !

SQL Server s'avère 4,5 fois plus rapide que PostGreSQL.

SELECT CODE_COM, NOM_COM, C.CODE_DEPT, C.NOM_DEPT, C.GEOM
FROM   S_GEO.COMMUNE AS C
       JOIN S_GEO.DEPARTEMENT AS D
            ON C.CODE_DEPT = D.CODE_DEPT
            AND ST_Intersects(C.GEOM, ST_Centroid(D.GEOM)) = true;

SELECT CODE_COM, NOM_COM, C.CODE_DEPT, C.NOM_DEPT, C.GEOM
FROM  S_GEO.COMMUNE AS C
       JOIN S_GEO.DEPARTEMENT AS D
            ON C.CODE_DEPT = D.CODE_DEPT
            AND C.GEOM.STIntersects(D.GEOM.STCentroid()) = 1;

Les dix premiers résultats sont les suivants :

Les performances sont surprenantes : les deux systèmes montrent un écart de 63 fois en faveur de SQL Server ce qui est franchement exceptionnel ! Quelle peut en être la raison ? D'autant que là encore, les plans de requête sont quasi identiques !

SQL Server s'annonce 63 fois plus rapide que PostGreSQL.

Le résultat est la commune de Neuilly-sur-Marne.

WITH T AS (
SELECT CODE_COM, INSEE_COM, NOM_COM, ST_Area(GEOM) AS SURFACE, GEOM,
       RANK() OVER(ORDER BY ABS(ST_Area(GEOM) - 6666666)) AS RANK_DIF
FROM   S_GEO.COMMUNE)
SELECT CODE_COM, INSEE_COM, NOM_COM, GEOM, SURFACE
FROM   T
WHERE RANK_DIF = 1;

WITH T AS (
SELECT CODE_COM, INSEE_COM, NOM_COM, GEOM.STArea() AS SURFACE, GEOM,
       RANK() OVER(ORDER BY ABS(GEOM.STArea() - 6666666)) AS RANK_DIF
FROM  S_GEO.COMMUNE)
SELECT CODE_COM, INSEE_COM, NOM_COM, GEOM, SURFACE
FROM  T
WHERERANK_DIF = 1;

La différence de performance est assez peu importante, mais en faveur de SQL Server.

En revanche, la différence de plan de requête est importante.

SQL Server faisant du parallélisme à l'aide de 48 threads dans deux séquences différentes identifiées par un demi-cadre rouge dans la figure 21.

Nous avons testé de nouveaux résultats en augmentant le niveau de parallélisme progressivement depuis un thread (donc pas de parallélisme), jusqu'à 48 pour SQL server. Voici la courbe des temps obtenus (figure 22) :

À l'évidence on constate qu'au-delà de 30, le temps se stabilise et qu'il est déjà très bon, aux alentours de 20.

La conclusion est que SQL Server mobilise beaucoup plus de ressources que PostGreSQL pour une performance très voisine, et que le réglage de la limite du parallélisme dans SQL Server n'est pas un vaine tâche (personnellement je conseille d'être toujours en dessous de la moitié du nombre de cœurs, et dans ce cas précis 20 me va bien !)

SQL Server s'annonce 1,7 fois plus rapide que PostGreSQL.

Une très légère différence de résultat apparaît due aux calculs arrondis :

Mais cette différence est bien inférieure au millimètre !

SELECT CLASS_ADM, SUM(ST_Length(GEOM)) / 1000 AS LONGUEUR_KM
FROM   S_RTE.TRONCON_ROUTE
WHERE CLASS_ADM <> 'Sans objet'
GROUP BY CLASS_ADM

SELECT CLASS_ADM, SUM(GEOM.STLength()) / 1000 AS LONGUEUR_KM
FROM  S_RTE.TRONCON_ROUTE
WHERECLASS_ADM <> 'Sans objet'
GROUPBY CLASS_ADM;

Au niveau des performances, les temps mesurés sont similaires…

Temps similaires, léger avantage à SQL Server (3,11 %).

La requête fait appel à une jointure spatiale et un agrégat (SUM) sur la longueur des géométries et y ajoute un tri du résultat qui comporte 41 145 lignes.

Notons que PostGreSQL présente les chaines vides en fin de tri alphabétique ce qui n'est pas conforme au jeu de caractères ni à la séquence de collation (french_france_1252).

Le plan PostGreSSQL (figure 23) est simple, tandis que celui de SQL Server est assez complexe utilisant à la fois une recherche sur l'index spatial pour les tronçons et sur l'index de la clef primaire (de type clustered) pour le reste des informations de la même table. On note une importante séquence parallélisée (mise en évidence en vert dans la figure 24) comportant 18 opérations sur les 21 que compte le plan.

Il semble évident que la version 1.1 de pgAdmin 4 n'est pas du tout stable et les nombreux bogues déjà évoqués la rendent difficilement exploitable.

SELECT D.CODE_DEPT, NUM_ROUTE, SUM(ST_Length(TR.GEOM)) / 1000 AS LONGUEUR_KM
FROM   S_RTE.TRONCON_ROUTE AS TR
       JOIN S_GEO.DEPARTEMENT AS D
            ON ST_Intersects(TR.GEOM, D.GEOM) = true
GROUP BY D.CODE_DEPT, NUM_ROUTE
ORDER BY CODE_DEPT, NUM_ROUTE;

SELECT D.CODE_DEPT, NUM_ROUTE, SUM(TR.GEOM.STLength()) / 1000 AS LONGUEUR_KM
FROM  S_RTE.TRONCON_ROUTE AS TR
       JOIN S_GEO.DEPARTEMENT AS D
            ON TR.GEOM.STIntersects(D.GEOM) = 1
GROUPBY D.CODE_DEPT, NUM_ROUTE
ORDER BY CODE_DEPT, NUM_ROUTE;

SQL Server s'annonce 6,4 fois plus rapide que PostGreSQL.

"C:\Program Files\PostgreSQL\9.6\bin\pg_dump.exe" 
    --host localhost --port 5432 --username postgres
    --blobs --format=c -f "C:\SAVE_DB\DB_GEOPG.BAK" DB_GEO

BACKUP DATABASE DB_GEO TO DISK = 'C:\SAVE_DB\DB_GEO_SQLSERVER.BAK'

"C:\Program Files\PostgreSQL\9.6\bin\pg_dump.exe"
    --host localhost --port 5432 --username postgres 
    --blobs --format=d -f "C:\SAVE_DB\DB_GEOPG.BAK" DB_GEO

BACKUP DATABASE DB_GEO TO DISK = 'C:\SAVE_DB\DB_GEO_SQLSERVER.BAK2'
WITH COMPRESSION

"C:\Program Files\PostgreSQL\9.6\bin\pg_dump.exe" 
    -j 8 --host localhost --port 5432 --username postgres 
    --blobs --format=d -f "C:\SAVE_DB\DB_GEOPG2.BAK" DB_GEO

BACKUP DATABASE DB_GEO
TO DISK = 'C:\SAVE_DB\DB_GEO_SQLSERVER.BAK31',
   DISK = 'D:\SAVE_DB\DB_GEO_SQLSERVER.BAK32'

BACKUP DATABASE DB_GEO
TO DISK = 'C:\SAVE_DB\DB_GEO_SQLSERVER.BAK41',
   DISK = 'D:\SAVE_DB\DB_GEO_SQLSERVER.BAK42'
WITH COMPRESSION

Au mieux, pour la sauvegarde, PostGreSQL met presque quatre fois plus de temps que SQL Server en mode compressé avec deux destinations. La taille de la sauvegarde est en revanche 11 % moins volumineuse avec la sauvegarde PostGreSQL que le fichier SQL Server de sauvegarde résultant. En multipliant le parallélisme des destinations, SQL Server permet de diminuer très sensiblement le temps de réponse.

"C:\Program Files\PostgreSQL\9.6\bin\pg_restore.exe"
    -U postgres -d DB_GEO "C:\SAVE_DB\DB_GEOPG.BAK"

RESTORE DATABASE DB_GEO FROM DISK = 'C:\SAVE_DB\DB_GEO_SQLSERVER.BAK'

"C:\Program Files\PostgreSQL\9.6\bin\pg_restore.exe"
    -j 8 -U postgres -d DB_GEO "C:\SAVE_DB\DB_GEOPG.BAK"

RESTORE DATABASE DB_GEO FROM DISK = 'C:\SAVE_DB\DB_GEO_SQLSERVER.BAK2'

RESTORE DATABASE DB_GEO
FROM DISK = 'C:\SAVE_DB\DB_GEO_SQLSERVER.BAK31',
     DISK = 'D:\SAVE_DB\DB_GEO_SQLSERVER.BAK32'

RESTORE DATABASE DB_GEO
FROM DISK = 'C:\SAVE_DB\DB_GEO_SQLSERVER.BAK41',
     DISK = 'D:\SAVE_DB\DB_GEO_SQLSERVER.BAK42'

Au mieux, pour la restauration, PostGreSQL met deux fois plus de temps que SQL Server en mode non compressé en utilisant huit threads.