IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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. #101
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202
    Par défaut
    Des minima sociaux par contre.
    Une discussion SQL pas académie française svp

  2. #102
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Sodium Voir le message
    … Sinon, si tu prends les langages serveur, on arrive à un petit 10.5% pour ASP.net et 7,9% d'ISS..
    Pour ton information, au cours d'un show Microsoft à la Porte Mailot au palais des congrès il y a un peu plus de 10 ans, le directeur de la R&D de Microsoft qui est un français, avait balancé en pleine discussion devant un millier d'auditeurs que Microsoft cherchait depuis plusieurs années à avoir un langage aussi productif que PHP… Et envisageaient d'abandonner ce projet pour apporter des éléments complémentaires à PHP. C'est ainsi que l'on a vu venir, peu après, des pilotes spécifique de SQL Server pour PHP…. Et c'est ainsi que Microsoft est passé d'un monde fermé (avec Steve Ballmer) à un monde ouvert (Satya Nadela) et est devenu aujourd'hui l'un des plus gros contributeur du libre…

    L'orientation de Microsoft est claire. C'est "Cloud First". Maintenant, je vous laisse deviner que est le système d'exploitation derrière SQL Azure par exemple...

    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #103
    Modérateur

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

    Informations professionnelles :
    Activité : DBA
    Secteur : Service public

    Informations forums :
    Inscription : Juin 2005
    Messages : 5 496
    Points : 12 596
    Points
    12 596
    Par défaut
    Citation Envoyé par SQLpro Voir le message

    L'orientation de Microsoft est claire. C'est "Cloud First". Maintenant, je vous laisse deviner que est le système d'exploitation derrière SQL Azure par exemple...
    Ca c'est facile c'est du Linux

  4. #104
    Expert éminent sénior
    Avatar de rawsrc
    Homme Profil pro
    Dev indep
    Inscrit en
    Mars 2004
    Messages
    6 142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 142
    Points : 16 545
    Points
    16 545
    Billets dans le blog
    12
    Par défaut
    Citation Envoyé par MaitrePylos Voir le message
    Ca c'est facile c'est du Linux
    taquineur, va !!

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

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Pour ton information, au cours d'un show Microsoft à la Porte Mailot au palais des congrès il y a un peu plus de 10 ans, le directeur de la R&D de Microsoft qui est un français, avait balancé en pleine discussion devant un millier d'auditeurs que Microsoft cherchait depuis plusieurs années à avoir un langage aussi productif que PHP… Et envisageaient d'abandonner ce projet pour apporter des éléments complémentaires à PHP. C'est ainsi que l'on a vu venir, peu après, des pilotes spécifique de SQL Server pour PHP…. Et c'est ainsi que Microsoft est passé d'un monde fermé (avec Steve Ballmer) à un monde ouvert (Satya Nadela) et est devenu aujourd'hui l'un des plus gros contributeur du libre…
    Et donc ça pour toi c'est une preuve de la compétence de Microsoft niveau serveurs ? On sait pas faire donc on va arrêter d'essayer ? Et donc c'est les meilleurs ? Non mais c'est une défense originale y a pas à dire.

    Citation Envoyé par SQLpro Voir le message
    L'orientation de Microsoft est claire. C'est "Cloud First". Maintenant, je vous laisse deviner que est le système d'exploitation derrière SQL Azure par exemple...
    Ben oui ils vendent leurs services ils ne vont pas utiliser l'OS d'en face... Donc c'est ton deuxième argument ? Les serveurs Microsoft sont supérieurs parce qu'ils sont utilisés par Microsoft ? Tu es trop fort, tu devrais te lancer comme négociateur dans les brigades anti-terroriste, tu as un avenir radieux.

  6. #106
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202

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

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    Mais non de toute façon Postgres c'est nul, c'est pas utilisé sur les serveurs Azure, il te faut quelle preuve de plus ?

  8. #108
    Membre émérite
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    Juin 2012
    Messages
    851
    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 : 851
    Points : 2 424
    Points
    2 424
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Et c'est ainsi que Microsoft est passé d'un monde fermé (avec Steve Ballmer) à un monde ouvert (Satya Nadela) et est devenu aujourd'hui l'un des plus gros contributeur du libre…
    contribue à quoi?

    kde?
    libreoffice?
    openjdk?
    gcc?
    linux autrement que leur driver?
    eclipse?
    Apache HTTP Server?
    postgres?
    mariadb?

    comment jugé de la qualité d'un commit? combien de ligne ajouté? combien d'enlevé?

    des stats de marketeux de patron pressé de github, on sait ce que ça vaut

  9. #109
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202
    Par défaut Benchmark tiers
    Setup
    J'ai fait un test sur une machine Ryzen 1800, 32GB DDR4 3000.
    Dual-boot : Windows 10 OEM à jour, Ubuntu 19.10 à jour.

    SQL Server express (2018 ?) tout frais téléchargé à l'instant.
    PostgreSQL 12.2 (Ubuntu 12.2-1.pgdg19.10+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008, 64-bit
    Au passage sqlserverexpress+ssms c'est environ 1.5GB de téléchargement; postgres+pgadmin4 installé depuis le dépôt pgdg c'est dans les 150MB.

    Je n'ai touché absolument à rien à la configuration de SQLServer (j'ai lu superficiellement qu'il pouvait utiliser toute la mémoire par défaut); j'ai augmenté à 500MB les shared_buffers dans pg_hba.conf. C'est une partie que je ne maîtrise pas du tout.

    Construire un jeu de données un peu plus intéressant

    Quel cruel manque de datasets libres au passage...data.gouv.fr est plutôt risible....
    J'ai pris grosso modo toute la comédie humaine de Zola et ai mis chaque mot dans une ligne de la table :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    curl -s https://www.ebooksgratuits.com/ebooks.php\?auteur\=Zola_Emile | sed -n 's/^.*href="newsendbook.php?id=\([0-9]*\)&format=epub.*$/\1/p' | xargs -Iyo curl -sL -o yo.epub https://www.ebooksgratuits.com/newsendbook.php\?id\=yo\&format\=epub
    ls *epub | xargs -Iyo ebook-convert yo yo.txt
    cat *.txt | awk '{split($0,a,"[[:space:][:punct:]]+");for(i in a){if(a[i]!=""){printf("%d,\"%s\"\n",VNR,a[i]);VNR++}}}' > yo.csv
    ebook-convert vient de la super liseuse Calibre.
    Le travail de préparation des données, c'est à des années lumière plus professionnel côté linux avec notamment les coreutils et les pipes unix...
    Cela donne un csv d'environ trois millions de lignes.
    Question clicougnette, l'import du csv prend 20 clics sur ssms, et littéralement 2 sur pgadmin4 - ce dernier outil est développé très rapidement depuis quelques mois, il commence à me bluffer, alors que je contribue à pgModeler.

    Alors c'est prêt, on y va :
    Côté postgres
    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
    CREATE COLLATION ignore_accents (provider = icu, locale = 'fr-u-ks-level1-kc-false', deterministic=false);
    CREATE TABLE t (ID SERIAL PRIMARY KEY, DATUM   VARCHAR(256) COLLATE ignore_accents);
     
    tidx=# select datum, count(datum) from t where datum ilike 'a' or datum ilike 'à' group by datum;
     datum | count
    -------+-------
     à     | 51163
     À     |  2309
     A     |    29
     a     |  6391
     
     tidx=# create statistics datum_stats on id, datum from t;
    CREATE STATISTICS
    tidx=# create index i on t (datum);
    CREATE INDEX
     
    tidx=# select count(datum) from t where datum='a';
     count
    -------
     59892
    (1 ligne)
     
     
    tidx=# explain analyze select count(datum) from t where datum='a';
                                                                QUERY PLAN
    ----------------------------------------------------------------------------------------------------------------------------------
     Aggregate  (cost=17323.10..17323.11 rows=1 width=8) (actual time=40.816..40.816 rows=1 loops=1)
       ->  Bitmap Heap Scan on t  (cost=1122.92..17179.07 rows=57612 width=5) (actual time=16.489..37.068 rows=59892 loops=1)
             Recheck Cond: ((datum)::text = 'a'::text)
             Heap Blocks: exact=15065
             ->  Bitmap Index Scan on i  (cost=0.00..1108.52 rows=57612 width=0) (actual time=14.798..14.798 rows=59892 loops=1)
                   Index Cond: ((datum)::text = 'a'::text)
     Planning Time: 0.087 ms
     Execution Time: 40.843 ms
    (8 lignes)
    Côté sqlserver

    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
    CREATE TABLE T (ID      BIGINT PRIMARY KEY,
                          DATUM   NVARCHAR(256) COLLATE French_CI_AI);
    
    create index i on T(datum);
    set statistics time on
    select count(*) from t where datum='a';
    set statistics time off
    
    Temps d'analyse et de compilation de SQL Server :
    , Temps UC = 0 ms, temps écoulé = 0 ms.
    
    SQL Server \endash Temps d'exécution :
    , Temps UC = 16 ms, temps écoulé = 114 ms.
    
    Rows    Executes    StmtText    StmtId    NodeId    Parent    PhysicalOp    LogicalOp    Argument    DefinedValues    EstimateRows    EstimateIO    EstimateCPU    AvgRowSize    TotalSubtreeCost    OutputList    Warnings    Type    Parallel    EstimateExecutions
    1    1    SELECT COUNT(*) FROM [t] WHERE [datum]=@1    1    1    0    NULL    NULL    NULL    NULL    1    NULL    NULL    NULL    0,2515709    NULL    NULL    SELECT    0    NULL
    0    0      |--Compute Scalar(DEFINE:([Expr1002]=CONVERT_IMPLICIT(int,[Expr1004],0)))    1    2    1    Compute Scalar    Compute Scalar    DEFINE:([Expr1002]=CONVERT_IMPLICIT(int,[Expr1004],0))    [Expr1002]=CONVERT_IMPLICIT(int,[Expr1004],0)    1    0    0    11    0,2515709    [Expr1002]    NULL    PLAN_ROW    0    1
    1    1           |--Stream Aggregate(DEFINE:([Expr1004]=Count(*)))    1    3    2    Stream Aggregate    Aggregate    NULL    [Expr1004]=Count(*)    1    0    0,0359357    11    0,2515709    [Expr1004]    NULL    PLAN_ROW    0    1
    59892    1                |--Index Seek(OBJECT:([test].[dbo].[T].[i]), SEEK:([test].[dbo].[T].[DATUM]=CONVERT_IMPLICIT(nvarchar(4000),[@1],0)) ORDERED FORWARD)    1    4    3    Index Seek    Index Seek    OBJECT:([test].[dbo].[T].[i]), SEEK:([test].[dbo].[T].[DATUM]=CONVERT_IMPLICIT(nvarchar(4000),[@1],0)) ORDERED FORWARD    NULL    59892    0,149597    0,0660382    9    0,2156352    NULL    NULL    PLAN_ROW    0    1
    
    A noter :
    • par défaut, sql server qui crée un clustered_index est effectivement beaucoup plus rapide, d'un facteur 3 à 4.
    • avec index des deux côtés, je suis assez loin de fanfaronner sur la "domination de postgres par rapport à son clone privatif", je concluerai pour ma part que les deux sont plutôt équivalents sur ce cas précis - sqlserver fait un index seek, le planner de postgres opte pour un bitmap index scan, le parcours matriciel fait sens vu le rapport volume de résultat/volume de recherche.


    Par ailleurs, je doute d'avoir envie de lire 90 pages comme celle ouvrant cette enfilade :

    • un bon benchmark a un description rigoureuse des configurations matérielle, système et logicielle,
    • un protocole de test et des résultats détaillés, synthétiques et jolis ...
    • ...sur un SCM.

    C'était une expérience intéressante et m'a fait entrevoir la vague envie de considérer à continuer sur un blog ici / un site dédié / une suite publique téléchargeable sur docker/guix orchestré.

  10. #110
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    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 : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par MaximeCh Voir le message
    Je n'ai touché absolument à rien à la configuration de SQLServer (j'ai lu superficiellement qu'il pouvait utiliser toute la mémoire par défaut)
    Tu as mal lu, SQL Server Express est limité à 1 Go.
    C'est d'ailleurs LE truc qui freine son utilisation quand on veut du 100% gratuit : cette limite est facilement atteinte et pénalise grandement les performances.
    Cependant, ici la table reste toute petite, donc 1 Go de mémoire est amplement suffisant.

    Pour ce qui est d'importer des données dans SQL Server, il y a la commande BULK INSERT https://docs.microsoft.com/fr-fr/sql...l-server-ver15
    Ça évite les 20 clics et probablement bien plus rapide (et scriptable).

    Pour le reste, il serait intéressant de refaire le test avec SQL Server et PostGreSQL sous le même OS.
    L'un et l'autre peuvent tourner sous Windows et sous Linux indifféremment.

    SSMS n'existe pas sous Linux, mais les outils en ligne de commande sont largement suffisants pour faire ce bench.
    https://docs.microsoft.com/fr-fr/sql...l-server-ver15
    On ne jouit bien que de ce qu’on partage.

  11. #111
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    719
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 719
    Points : 2 712
    Points
    2 712
    Par défaut Continue!
    Citation Envoyé par MaximeCh Voir le message
    J'ai fait un test sur une machine Ryzen 1800, 32GB DDR4 3000.
    [...]avec index des deux côtés, je suis assez loin de fanfaronner sur la "domination de postgres par rapport à son clone privatif", je concluerai pour ma part que les deux sont plutôt équivalents sur ce cas précis - sqlserver fait un index seek, le planner de postgres opte pour un bitmap index scan, le parcours matriciel fait sens vu le rapport volume de résultat/volume de recherche.
    Très intéressant. Et je suis d'accord avec ta conclusion, la différence est trop faible pour affirmer qu'un test très légèrement différent ne donnerait pas le résultat inverse.

    Pendant que tu y es, histoire de clôturer la bataille de méthodologie, est-ce que tu pourrais refaire le même test en remplaçant l'usage de la collation par la fonction unaccent, et même la fonction écrite en SQL? Dans les deux cas, avec et sans index? Juste histoire d'enfoncer le clou et de prouver qu'il faut comparer juste ce qui est comparable, et que donc le test de SQLPro était biaisé (je me doute bien que la fonction en SQL sera plus lente, mais ça m'intéresse de savoir de combien).
    Évidemment rien ne m'empêche de faire le test moi-même, seulement ce serait bien que tous les tests soient faits sur la même machine.

    De plus, les collations non déterministes ne sont disponibles que sur PostgreSQL 12, donc celui qui est bloqué à une version plus ancienne peut avoir besoin d'utiliser une autre méthode. Surtout si on se retrouve avec un cas non traité par les collations ou par unaccent (une langue rare par exemple, ou un ordre de tri spécifique à un métier). Donc même si l'usage des collations est l'idéal, ce n'est pas toujours possible.

    Citation Envoyé par MaximeCh Voir le message
    Je n'ai touché absolument à rien à la configuration de SQLServer (j'ai lu superficiellement qu'il pouvait utiliser toute la mémoire par défaut); j'ai augmenté à 500MB les shared_buffers dans pg_hba.conf. C'est une partie que je ne maîtrise pas du tout.
    Même si avoir tout en mémoire favorise le serveur qui utilise cette technique, je reste dubitatif sur la viabilité de cette méthode en utilisation réelle: il faudrait avoir un jeu de données nettement plus gros que la mémoire disponible (on pourrait refaire le test sur une vieille bécane avec moins de 1 GO de RAM). Parce que dans la vie réelle, je doute qu'on ait toujours plus de RAM que de données à traiter.

    Citation Envoyé par StringBuilder Voir le message
    Pour ce qui est d'importer des données dans SQL Server, il y a la commande BULK INSERT https://docs.microsoft.com/fr-fr/sql...l-server-ver15
    Ça évite les 20 clics et probablement bien plus rapide (et scriptable).
    ça porte un autre nom mais ça existe aussi pour PostgreSQL

  12. #112
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    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 : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    J'ai quelques questions à propos de PostgreSql version 12.

    Histoire de voir ce que donnent les différents benchs sur ma machine, je tente de l'installer sur une VM.

    Lorsque je regarde la documentation de SQL Server, je vois que parmi les versions préconisés, il y a ubuntu 16.04 LTS. https://docs.microsoft.com/fr-fr/sql...l-server-ver15
    J'ai pas bien compris pourquoi il n'y a pas la version 18.04 ou 19.01 mais après être resté bloqué avec une Debian puis avoir galeré avec la ubuntu 18.04 je préfère rester dans les clous de l'éditeur cette fois.

    Je me lance donc dans l'installation de PostgreSQL.
    Je suis bêtement cette doc indiquant comment installer PG sur ubuntu 16.04 : https://www.digitalocean.com/communi...n-ubuntu-16-04

    Rien de bien surprenant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    apt-get install postgresql postgresql-contrib
    Et là, c'est le drame : ça m'installe une version 9.5

    Donc la version "officielle" de PG, c'est 9.5 ou 12 ? Quel est le statut de la 12 ? Elle est LTS ? Beta ? Où sont passés les versions 10 et 11 ?
    On ne jouit bien que de ce qu’on partage.

  13. #113
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    719
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 719
    Points : 2 712
    Points
    2 712
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    Donc la version "officielle" de PG, c'est 9.5 ou 12 ? Quel est le statut de la 12 ? Elle est LTS ? Beta ? Où sont passés les versions 10 et 11 ?
    Toutes les versions de PostgreSQL sont supportées 5 ans à partir de la sortie de la version officielle (pas de la béta). Il n'y a donc pas de différence entre une LTS et une autre, ou alors toutes sont des LTS.
    La dernière stable c'est la 12, mais les 9.4, 9.5, 10 et 11 sont encore maintenues, mais uniquement pour corriger des bugs ou failles de sécurité. Pour les nouvelles fonctionnalités, c'est la 13 qui n'en est même pas encore à la béta.

    Citation Envoyé par StringBuilder Voir le message
    Je suis bêtement cette doc indiquant comment installer PG sur ubuntu 16.04 : https://www.digitalocean.com/communi...n-ubuntu-16-04

    Et là, c'est le drame : ça m'installe une version 9.5
    En effet, le fait que Ubuntu 16.04 soit en LTS signifie qu'elle met à jour les logiciels mais uniquement pour les corrections (bugs ou failles de sécurité), pas les versions majeures!
    Donc si la dernière stable en avril 2016 était la 9.5, seules les mises à jour mineures (de 9.5.0 à actuellement 9.5.21) seront apportées par la distribution.

    C'est d'autant plus vrai avec PostgreSQL pour une autre raison: migrer une base de la version 9.5 à la version 12 n'est pas une opération qui peut être faite automatiquement. Donc le gars qui a installé une Ubuntu en 2016 n'a peut-être pas envie de passer du temps à migrer toutes ses bases ... sauf évidemment quand PostgreSQL 9.5 passera en phase out, et vu le rythme de sortie, Ubuntu aura produit une nouvelle LTS d'ici là.

    Par contre, une chose qui est très bien avec Debian (et donc avec Ubuntu qui en est dérivée) c'est qu'il est assez facile de faire cohabiter la version 9.5 proposée par la distribution et la version 12, même simultanément (avec d'autres distributions c'est toujours possible mais pas forcément aussi facile), ce qui est très bien pour des tests comparatifs ou de non régression par exemple. C'est exactement ce que j'ai fait pour le test que je détaille dans un message précédent, car je ne souhaitais pas migrer des bases en cours d'utilisation. La seule chose à faire, c'est qu'avant de faire l'installation dans Ubuntu, il faut ajouter manuellement le repository de PostgreSQL en complément de celui d'Ubuntu (petite précision, même si cette page parle de la version 11, le repository ne change pas, il pointe désormais sur la 12). Ensuite, si une ancienne version est déjà installée, il se débrouillera pour installer la 12 avec un port différent, ce qui leur permet de cohabiter facilement.

  14. #114
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202
    Par défaut hop
    Citation Envoyé par esperanto Voir le message
    est-ce que tu pourrais refaire le même test en remplaçant l'usage de la collation par la fonction unaccent, et même la fonction écrite en SQL? Dans les deux cas, avec et sans index?
    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
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
     
    tidx=# create extension unaccent;
    tidx=# CREATE TABLE t2 (ID SERIAL PRIMARY KEY, DATUM   VARCHAR(256));
    -- "/usr/bin/psql" --command " "\\copy public.t2 (id, datum) FROM '.../yo.csv' CSV QUOTE '\"' ESCAPE '''';""
     
     
    tidx=# select count(datum) from t2 where unaccent(datum)='a';
     count
    -------
     57554
    (1 ligne)
     
    tidx=# explain analyze select count(datum) from t2 where unaccent(datum)='a';
                                                                 QUERY PLAN
    ------------------------------------------------------------------------------------------------------------------------------------
     Finalize Aggregate  (cost=50941.68..50941.69 rows=1 width=8) (actual time=309.573..309.573 rows=1 loops=1)
       ->  Gather  (cost=50941.47..50941.68 rows=2 width=8) (actual time=309.546..314.113 rows=3 loops=1)
             Workers Planned: 2
             Workers Launched: 2
             ->  Partial Aggregate  (cost=49941.47..49941.48 rows=1 width=8) (actual time=291.853..291.854 rows=1 loops=3)
                   ->  Parallel Seq Scan on t2  (cost=0.00..49925.42 rows=6420 width=5) (actual time=0.538..290.831 rows=19185 loops=3)
                         Filter: (unaccent((datum)::text) = 'a'::text)
                         Rows Removed by Filter: 1007759
     Planning Time: 0.160 ms
     Execution Time: 314.148 ms
    (10 lignes)
     
    tidx=# create or replace function unaccent2(txt varchar(256)) returns varchar(256) as $$ select unaccent(txt); $$ language sql immutable;
    CREATE FUNCTION
     
    tidx=# explain analyze select count(datum) from t2 where unaccent2(datum)='a';
                                                        QUERY PLAN
    -------------------------------------------------------------------------------------------------------------------
     Aggregate  (cost=839559.10..839559.11 rows=1 width=8) (actual time=5161.691..5161.691 rows=1 loops=1)
       ->  Seq Scan on t2  (cost=0.00..839520.59 rows=15407 width=5) (actual time=44.941..5158.527 rows=57554 loops=1)
             Filter: ((unaccent2(datum))::text = 'a'::text)
             Rows Removed by Filter: 3023278
     Planning Time: 0.078 ms
     JIT:
       Functions: 5
       Options: Inlining true, Optimization true, Expressions true, Deforming true
       Timing: Generation 0.807 ms, Inlining 6.440 ms, Optimization 27.372 ms, Emission 10.947 ms, Total 45.565 ms
     Execution Time: 5162.546 ms
    (10 lignes)
     
     
    tidx=# create index i2 on t2(unaccent2(datum));
    CREATE INDEX
     
    tidx=# explain analyze select count(datum) from t2 where unaccent2(datum)='a';
                                                            QUERY PLAN
    ---------------------------------------------------------------------------------------------------------------------------
     Aggregate  (cost=20244.30..20244.31 rows=1 width=8) (actual time=34.059..34.059 rows=1 loops=1)
       ->  Bitmap Heap Scan on t2  (cost=299.81..20205.79 rows=15404 width=5) (actual time=9.453..30.367 rows=57554 loops=1)
             Recheck Cond: ((unaccent2(datum))::text = 'a'::text)
             Heap Blocks: exact=15002
             ->  Bitmap Index Scan on i2  (cost=0.00..295.96 rows=15404 width=0) (actual time=7.380..7.380 rows=57554 loops=1)
                   Index Cond: ((unaccent2(datum))::text = 'a'::text)
     Planning Time: 0.106 ms
     Execution Time: 34.085 ms
    (8 lignes)
     
    tidx=# CREATE OR REPLACE FUNCTION remove_fr_accents(string text)
    tidx-# RETURNS text
    tidx-# AS $$
    tidx$# DECLARE out_str text;
    tidx$# BEGIN
    tidx$#    SELECT translate(string, 'âäàÁÂÄèéêëÈÉÊËîïÎÏôöÕÖùûüÙÛÜÿ?Çç',
    tidx$#                             'aaaAAAeeeeEEEEiiIIooOOuuuUUUyYCc')
    tidx$#           INTO out_str;
    tidx$#    SELECT replace(out_str, '?', 'OE') INTO out_str;
    tidx$#    SELECT replace(out_str, 'Æ', 'AE') INTO out_str;
    tidx$#    SELECT replace(out_str, 'æ', 'ae') INTO out_str;
    tidx$#    SELECT replace(out_str, '?', 'oe') INTO out_str;
    tidx$#    RETURN out_str;
    tidx$# END;
    tidx$# $$ LANGUAGE plpgsql immutable;
    CREATE FUNCTION
     
    tidx=# select count(datum) from t2 where remove_fr_accents(datum)='a';
     count
    -------
     57554
    (1 ligne)
     
    tidx=# explain analyze select count(datum) from t2 where remove_fr_accents(datum)='a';
                                                         QUERY PLAN
    --------------------------------------------------------------------------------------------------------------------
     Aggregate  (cost=824092.91..824092.92 rows=1 width=8) (actual time=29187.786..29187.786 rows=1 loops=1)
       ->  Seq Scan on t2  (cost=0.00..824054.40 rows=15404 width=5) (actual time=49.347..29183.283 rows=57554 loops=1)
             Filter: (remove_fr_accents((datum)::text) = 'a'::text)
             Rows Removed by Filter: 3023278
     Planning Time: 0.057 ms
     JIT:
       Functions: 5
       Options: Inlining true, Optimization true, Expressions true, Deforming true
       Timing: Generation 0.881 ms, Inlining 13.959 ms, Optimization 23.250 ms, Emission 10.248 ms, Total 48.337 ms
     Execution Time: 29188.749 ms
    (10 lignes)
     
     
    tidx=# create index i3 on t2(remove_fr_accents(datum));
    CREATE INDEX
     
    tidx=# explain analyze select count(datum) from t2 where remove_fr_accents(datum)='a';
                                                            QUERY PLAN
    ---------------------------------------------------------------------------------------------------------------------------
     Aggregate  (cost=30226.49..30226.50 rows=1 width=8) (actual time=32.971..32.971 rows=1 loops=1)
       ->  Bitmap Heap Scan on t2  (cost=299.81..30187.98 rows=15404 width=5) (actual time=8.381..29.192 rows=57554 loops=1)
             Recheck Cond: (remove_fr_accents((datum)::text) = 'a'::text)
             Heap Blocks: exact=15006
             ->  Bitmap Index Scan on i3  (cost=0.00..295.96 rows=15404 width=0) (actual time=5.620..5.620 rows=57554 loops=1)
                   Index Cond: (remove_fr_accents((datum)::text) = 'a'::text)
     Planning Time: 0.074 ms
     Execution Time: 33.004 ms
    (8 lignes)
    A noter : ni unaccent(), ni remove_fr_accents() ne s'intéressent à la casse, l'ensemble retourné est donc plus petit qu'avec la collation 'CI AI'.

  15. #115
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202
    Par défaut Trop de complexité pour une personne : benchmark par équipes?
    Une équipe neutre qui fait vivre une suite de cas d'usage, avec données ouvertes.

    Une équipe SQL Server, une autre PostgreSQL : chacune montre le meilleur actuel de sa solution par rapport aux besoins.
    L'équipe neutre analyse, synthétise et publie les résultats.

    Est-ce que ça ne serait pas un super moyen pour y voir plus clair?

  16. #116
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    719
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 719
    Points : 2 712
    Points
    2 712
    Par défaut Intéressant
    Merci Maxime, les tests sont très intéressants

    La première chose qu'on constate, c'est que quand l'index est créé correctement (avec la fonction, contrairement à ce qu'avait fait SQLPro) les performances sont largement comparables à l'usage de la collation (40 ms contre 34 ms). Le plus surprenant étant encore que la fonction remove_fr_accents, après indexation, ait les mêmes performances que unaccent2 qui fait pourtant appel à du code C.
    Par contre ça montre bien qu'une fonction en SQL ne peut rivaliser avec une fonction C, au moins avant indexation, en témoigne la différence entre unaccent (314 ms sans index) et unaccent2 (5162 ms, là je suis un peu surpris quand même). Et aussi bien sûr l'importance de bien choisir son index, l'usage d'indexes sur fonction s'avérant très efficace.
    Et quand bien même, on se rend compte qu'avec de vraies données (quand l'index comprend un peu plus de deux valeurs uniques), le rapport de 1 pour 300 000 est purement fantaisiste, tout au plus on est à 1 pour 250 dans le pire des cas (29 secondes sans index ni collation contre 116 ms avec collation et index de l'autre...)

    Citation Envoyé par MaximeCh Voir le message
    A noter : ni unaccent(), ni remove_fr_accents() ne s'intéressent à la casse, l'ensemble retourné est donc plus petit qu'avec la collation 'CI AI'.
    C'est vrai il faudrait peut-être essayer de combiner avec lower, y compris dans l'index bien évidemment...

  17. #117
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Le plus surprenant étant encore que la fonction remove_fr_accents, après indexation, ait les mêmes performances que unaccent2 qui fait pourtant appel à du code C.
    Ce que je comprends c'est que le coût d'exécution de la fonction est déporté au moment de la création de l'index. Pendant la requête, le parcours ou la recherche dans l'index retourne les valeurs pré-calculées stockées dans l'index lui-même.

  18. #118
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    719
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 719
    Points : 2 712
    Points
    2 712
    Par défaut Cout de l'index.
    Citation Envoyé par MaximeCh Voir le message
    Ce que je comprends c'est que le coût d'exécution de la fonction est déporté au moment de la création de l'index. Pendant la requête, le parcours ou la recherche dans l'index retourne les valeurs pré-calculées stockées dans l'index lui-même.
    Exact. Ça vaudrait le coup de rajouter le coût de la création de l'index (en activant \timing on dans le client psql) du coup

  19. #119
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202
    Par défaut
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    tidx=# create index i2 on t2(unaccent2(datum));
    CREATE INDEX
    Durée : 10757,598 ms (00:10,758)
     
    tidx=# create index i3 on t2(remove_fr_accents(datum));
    CREATE INDEX
    Durée : 32279,395 ms (00:32,279)

  20. #120
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    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 : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Le plus surprenant étant encore que la fonction remove_fr_accents, après indexation, ait les mêmes performances que unaccent2 qui fait pourtant appel à du code C.
    Sauf erreur de ma part, cela n'a rien de surprenant :

    Lorsque tu crées un index utilisant une fonction, le temps d'interrogation de la colonne est le même que ce soit une colonne calculée ou non.
    Donc ici, la seule différence mesurable, c'est le temps qu'ont mis les fonctions à traiter les valeurs littérales 'a'
    A ce moment, on se rend compte que les quelques millisecondes sont énormes, puisque c'est la différence nécessaire pour traiter une seule chaîne d'un seul caractère.

    On peut en déduire par conséquent que la fonction d'indexation sera fortement pénalisée par la fonction SQL par rapport à la fonction C.
    On ne jouit bien que de ce qu’on partage.

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