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

 SGBD Discussion :

PostGreSQL vs Microsoft SQL Server - Partie 1 : performances des commandes pour le DBA [Tutoriel]


Sujet :

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
    20 945
    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 : 20 945
    Points : 49 762
    Points
    49 762
    Billets dans le blog
    1
    Par défaut PostGreSQL vs Microsoft SQL Server - Partie 1 : performances des commandes pour le DBA
    Chers membres du club,

    J'ai le plaisir de vous présenter cet article :


    Ce premier papier parle de quelques comparaisons entre PostGreSQL et SQL Server et pointe les différences en termes de performances pour quelques-unes des requêtes et commandes administratives qu’un DBA ordinaire doit exécuter.
    Bonne lecture

    Retrouvez les meilleurs cours et tutoriels pour apprendre les SGBD et SQL
    .
    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/ * * * * *

  2. #2
    Membre régulier
    Avatar de RenardSpatial
    Homme Profil pro
    *
    Inscrit en
    novembre 2018
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : *

    Informations forums :
    Inscription : novembre 2018
    Messages : 11
    Points : 77
    Points
    77
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    Merci pour cette analyse.

    Pour commencer, je n’ai pas réussi à télécharger les requêtes mentionnées au point IX : le premier lien en 1drv.ms me demande un mot de passe, le second interne à developper.com me demande d’être connecté alors que je le suis déjà.

    J’essaie de comprendre ce que je pourrais en déduire quant aux choix des futures bases de données de mes projets, et à cet effet j’aurais quelques questions. Je précise que je fais du devops mais ne suis pas DBA professionnel, ce qui pourrait expliquer quelques naïvetés dans mes questions.

    1. Il me semble que PostgreSQL est plutôt utilisé sous Linux que sous Windows. Ne serait-il pas plus pertinent de comparer les deux SGBD sur leurs OS de prédilection ?
    2. Qu’est-ce qui justifie d’avoir une configuration spécifique pour PostgreSQL mais pas pour SQL Server ?
    3. Serait-il possible de savoir ce qui a guidé le choix des valeurs de configuration pour PostgreSQL (dans la logique plus que dans le détail)
    4. Je vois que PostgreSQL a un encodage en UTF8 mais une collation et un type de caractères qui me semble être liée à Windows (1252), ça ne pose pas de problèmes ?
    5. Je ne comprends pas la pertinence de l’argument suivant : « Nous avons dû créer une collation pour PostGreSQL pour la deuxième table, car PostGreSQL possède très peu de collations internes contrairement à SQL Server qui en a plus de 5500. », puisque PostgreSQL gère nativement à peu près toutes les collations possibles en utilisant les collations ICU tel que défini aux chapitre 23.2.2.2 et 23.2.2.3 de la documentation – ce qui rends sa quantité de collations virtuellement infinie, ce qui est plus que les 5500 internes à SQL Server.
    6. Vous donnez des moyennes mais aucune autre information, en particulier pas l’écart-type des mesures. Est-ce que les mesures sont stables ou est-ce que les temps trouvés peuvent varier d’un gros facteur (ce qui pourrait changer la conclusion) ?

    Et surtout, je ne vois aucune tentative d’analyse de l’écart.

    Pourtant, ce que vous montrez là est intéressant : il semblerait que MS SQL soit sensiblement plus performant que PostgreSQL, mais sans que l’on sache quelle est la cause de cet écart. Pourtant un facteur 20 ou 30 est quelque chose d’assez énorme qui mériterait de s’y intéresser : est-ce dû aux SGBD eux-mêmes ? À un défaut de configuration ? Quels sont les facteurs limitants dans les deux cas (limitation par le CPU, mauvaise parallélisation par le SGBD, limitation par les I/O, par la bande passante mémoire, de la collation spécifique PostgreSQL…). En particulier on ne sait pas sur quel type de disques sont stockées les données, si ce sont des disques durs, l’écart est-il le même avec des SSD ? Etc.

    C’est dommage que votre article se soit arrêté aux chiffres bruts, sans aucune analyse ni aucune recherche de détail. En l’état, il est difficile d’en tirer quoi que ce soit de probant, et il me donne plutôt l’impression que vous vous êtes arrêté dès que vous avez obtenu des chiffres qui montrent que SQL Server est plus rapide que PostgreSQL. J’espère me tromper et que votre réponse me montrera que vous étiez de bonne foi en créant ce test. Cela me semble d’autant plus important que, puisque vous êtes « Microsoft® Most Valuable Professional », on pourrait vite croire que vous êtes là plus pour vendre les solutions de Microsoft – à qui vous êtes affiliés – que pour faire des tests neutres et impartiaux.

    Enfin je me permet de signaler une erreur récurrente, la typographie nominale est « PostgreSQL » et non « PostGreSQL » (le g central n’est pas en majuscule).

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 945
    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 : 20 945
    Points : 49 762
    Points
    49 762
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    Citation Envoyé par RenardSpatial Voir le message
    Bonjour,

    Merci pour cette analyse.

    ...

    Enfin je me permet de signaler une erreur récurrente, la typographie nominale est « PostgreSQL » et non « PostGreSQL » (le g central n’est pas en majuscule).
    J'assume parfaitement ce qui vous apparait comme une erreur typographique et qui est ma signature de tout temps au sujet de PostGreSQL. Sachez que les noms n'ont pas d'orthographe précise et que PostGreSQL n'est visiblement pas une "trademark". On n'est donc pas obligé de respecter la typologie de la communauté (ou serait donc la liberté si on me l'imposait comme semble vouloir me le faire remarquer les intégristes de PG...). De plus PostGreSQL c'est la suite de InGreSQL (notez là aussi le G majuscule, que je n'utilise en principe jamais pour Ingres....) un simple jeu de mot ayant guidé le choix de PostGreSQL à l'origine PostGres (sans le SQL) qui signifie après "gres" alors qu'avant c'était dans "gres". C'est là sans doute mon aspect vieux con qui après 34 ans passé dans les SGBDR m'en a fait connaître l'histoire et les principaux (DB2, Oracle, Sybase SQL Server, Watcom, RDB, Gupta SQL, Informix, InterBase et bien d'autres....) pour ne plus me consacrer qu'à quelques uns (MS SQL Server, Oracle, PostGreSQL...).
    Ne pas oublier le pourquoi du "Ingres"... C'est tout simplement lié à la naissance du free... En effet, Eugene Wong et Michael Stonebraker ont démarré le développement de Ingres à temps perdu (perruque) et dont décidé de la baptisé du nom d'Ingres à cause de son violon...


    Citation Envoyé par RenardSpatial Voir le message
    Pour commencer, je n’ai pas réussi à télécharger les requêtes mentionnées au point IX : le premier lien en 1drv.ms me demande un mot de passe, le second interne à developper.com me demande d’être connecté alors que je le suis déjà.
    Je viens de réinitialiser le lien OneDrive, mais je ne puis tester :
    https://1drv.ms/u/s!AqvZfiQYoNpBihI4...hRZec?e=nwpcaM
    Pour DVP je n'y suis pour rien, je vois avec les responsables...


    Citation Envoyé par RenardSpatial Voir le message
    J’essaie de comprendre ce que je pourrais en déduire quant aux choix des futures bases de données de mes projets, et à cet effet j’aurais quelques questions. Je précise que je fais du devops mais ne suis pas DBA professionnel, ce qui pourrait expliquer quelques naïvetés dans mes questions.

    Il me semble que PostgreSQL est plutôt utilisé sous Linux que sous Windows. Ne serait-il pas plus pertinent de comparer les deux SGBD sur leurs OS de prédilection ?
    Cela n'aurait pas fait de remarquables différences l'écart étant déjà très important et SQL Server marchant un peu mieux (de l'ordre de 5 à 8 %) sous Linux.... Et il me semble qu'il y a pas mal de PG sous Windows...

    Citation Envoyé par RenardSpatial Voir le message
    Qu’est-ce qui justifie d’avoir une configuration spécifique pour PostgreSQL mais pas pour SQL Server ?
    PG est réglé lors de son installation avec des paramètres qui sous-utilisent les ressources. Les laisser tels quelle pour faire les tests aurait sévèrement handicapé PostGreSQL. SQL Server, est auto paramétré. D'une part lors de son installation avec les valeurs par défaut, d'autre part dynamiquement dans son exploitation. En particulier dans les toutes dernières versions, aucun réglage n'est strictement nécessaire pour les performances, sauf le paramétrage du "optimize for adhoc workload" qu'il aurait été judicieux d'activer pour économiser du cache pour les requêtes unitaires. Mais avec 128 Go de RAM, c'était parfaitement inutile.

    Citation Envoyé par RenardSpatial Voir le message
    Serait-il possible de savoir ce qui a guidé le choix des valeurs de configuration pour PostgreSQL (dans la logique plus que dans le détail)
    Mon expérience et les documents de référence suivant :
    https://wiki.postgresql.org/wiki/Tun...tgreSQL_Server
    https://pgtune.leopard.in.ua/#/
    ...


    Citation Envoyé par RenardSpatial Voir le message
    Je vois que PostgreSQL a un encodage en UTF8 mais une collation et un type de caractères qui me semble être liée à Windows (1252), ça ne pose pas de problèmes ?
    Pour des requêtes de DBA, n'importe quel type de données et n'importe quel collation aurait permis la comparaison. Charge à vous de prouver le contraire, raison pour laquelle j'ai laissé les fichiers et les requêtes en libre disposition...

    Citation Envoyé par RenardSpatial Voir le message
    Je ne comprends pas la pertinence de l’argument suivant : « Nous avons dû créer une collation pour PostGreSQL pour la deuxième table, car PostGreSQL possède très peu de collations internes contrairement à SQL Server qui en a plus de 5500. », puisque PostgreSQL gère nativement à peu près toutes les collations possibles en utilisant les collations ICU tel que défini aux chapitre 23.2.2.2 et 23.2.2.3 de la documentation – ce qui rends sa quantité de collations virtuellement infinie, ce qui est plus que les 5500 internes à SQL Server.
    Oui, mais il faut les créer. Cette étape n'existe pas dans SQL Server qui les gèrent directement. De plus les collations ICU sont inexploitable comme le montre cet article car buguées...

    Citation Envoyé par RenardSpatial Voir le message
    Vous donnez des moyennes mais aucune autre information, en particulier pas l’écart-type des mesures. Est-ce que les mesures sont stables ou est-ce que les temps trouvés peuvent varier d’un gros facteur (ce qui pourrait changer la conclusion) ?
    Et surtout, je ne vois aucune tentative d’analyse de l’écart.
    À part une seule requête pour laquelle il y a eut un écart important pour PostGreSQL, la variance est très ramassée. Je ne me souviens plus de laquelle, mais je pourrais la retrouver. Mais elle n'était pas significative dans la comparaison finale, raison pour laquelle je ne l'ai pas mentionnée dans l'article.

    Citation Envoyé par RenardSpatial Voir le message
    Pourtant, ce que vous montrez là est intéressant : il semblerait que MS SQL soit sensiblement plus performant que PostgreSQL, mais sans que l’on sache quelle est la cause de cet écart. Pourtant un facteur 20 ou 30 est quelque chose d’assez énorme qui mériterait de s’y intéresser : est-ce dû aux SGBD eux-mêmes ? À un défaut de configuration ? Quels sont les facteurs limitants dans les deux cas (limitation par le CPU, mauvaise parallélisation par le SGBD, limitation par les I/O, par la bande passante mémoire, de la collation spécifique PostgreSQL…). En particulier on ne sait pas sur quel type de disques sont stockées les données, si ce sont des disques durs, l’écart est-il le même avec des SSD ? Etc.
    Ces opérations sont à 95% des opérations logiques ayant très peu d'IO physiques. L'influence des disques est donc très peu significative et utiliser tel ou tel type de stockage n'aurait pas montré de différence.
    Défaut de configuration, à moins que je n'ai fait une grossière erreur pour PG, je ne voit pas... (pour info j'ai mis parallel_workers à 48 mais aucune requête ne m'a montré un plan parallélisé)
    Bande passante, c'est le même PC...
    Ce qui est clair c'est que le parallélisme intervient pour la part la plus importante dans cette différence de performances. Depuis la version 7 datant de 1998 (22 ans donc), SQL Server fait du parallélisme massivement et de manière automatique dans toutes ses tâches, pas uniquement pour les requêtes (aucun réglage particulier à entreprendre). Les tris et donc les créations d'index sont parallélisés et peuvent utiliser tous les cœurs soit 48 dans notre test. Alors que PostGreSQL semble n'utiliser qu'un seul thread... De plus, même en paramétrant PG pour utiliser 48 cœurs, celui-ci m'a montré qu'il n'en utilisait jamais plus que 4 qui semble être actuellement une limite interne par conception...
    Enfin, la R&D de Microsoft a réalisé des algorithmes internes qui semble plus efficace que ceux bien connus que l'on trouve dans la littérature des SGBDR. Ce qui explique d'autres différences... Ce sont les petits secrets jalousement gardé par les grand éditeurs de SGBDR ! Mais rassurez-vous, certains experts de MS en matière de développement de moteurs de bases de données travaillent aussi pour la version free de PostGreSQL ! (Core team : Andres Freund, Major contributor : David Rowley...)

    Citation Envoyé par RenardSpatial Voir le message
    C’est dommage que votre article se soit arrêté aux chiffres bruts, sans aucune analyse ni aucune recherche de détail. En l’état, il est difficile d’en tirer quoi que ce soit de probant, et il me donne plutôt l’impression que vous vous êtes arrêté dès que vous avez obtenu des chiffres qui montrent que SQL Server est plus rapide que PostgreSQL. J’espère me tromper et que votre réponse me montrera que vous étiez de bonne foi en créant ce test.
    La bonne fois, la mauvaise foi... Tout est question d’appréciation. Moi je me contente de faits. Je les rends reproductible à tout un chacun, qui peut les analyser plus en profondeur, les disséquer et en publier une analyse. mais une analyse vaut ce qu'elle vaut : c'est un point de vue d'après des faits !

    Cependant ce forum est là pour effectivement compléter efficacement et intelligemment l'article que j'ai écrit... Et vos questions sont intéressantes !

    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/ * * * * *

  4. #4
    Community Manager

    Avatar de Malick
    Homme Profil pro
    Community Manager
    Inscrit en
    juillet 2012
    Messages
    8 632
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Community Manager
    Secteur : Conseil

    Informations forums :
    Inscription : juillet 2012
    Messages : 8 632
    Points : 80 073
    Points
    80 073
    Billets dans le blog
    15
    Par défaut
    Salut,

    Citation Envoyé par SQLpro
    Pour DVP je n'y suis pour rien, je voit avec les responsables...
    Je confirme que le lien de téléchargement interne est fonctionnel. Je vous le remet ici.
    Vous avez envie de contribuer au sein du Club Developpez.com ? Contactez-nous maintenant !
    Vous êtes passionné, vous souhaitez partager vos connaissances en informatique, vous souhaitez faire partie de la rédaction.
    Il suffit de vous porter volontaire et de nous faire part de vos envies de contributions :
    Rédaction d'articles/cours/tutoriels, Traduction, Contribution dans la FAQ, Rédaction de news, interviews et témoignages, Organisation de défis, de débats et de sondages, Relecture technique, Modération, Correction orthographique, etc.
    Vous avez d'autres propositions de contributions à nous faire ? Vous souhaitez en savoir davantage ? N'hésitez pas à nous approcher.

  5. #5
    Membre actif Avatar de Grulim
    Profil pro
    Inscrit en
    juillet 2004
    Messages
    234
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2004
    Messages : 234
    Points : 281
    Points
    281
    Par défaut
    Salut,

    Suite à cet article, je me demandais pourquoi il n'y avait pas plus de benchmark MS SQL Server vs ... et en cherchant un peu, je suis tombé sur ça :
    Benchmark Testing

    Customer must obtain Microsoft’s prior written approval to disclose to a third party the results of any benchmark test of any Server Product or Microsoft Desktop Optimization Pack.
    sur le site de microsoft (https://www.microsoft.com/licensing/...Software/EAEAS).

    Étonnant, non ?

  6. #6
    Membre expérimenté
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    juin 2012
    Messages
    591
    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 : 591
    Points : 1 498
    Points
    1 498
    Par défaut
    Citation Envoyé par Grulim Voir le message
    Salut,

    Suite à cet article, je me demandais pourquoi il n'y avait pas plus de benchmark MS SQL Server vs ... et en cherchant un peu, je suis tombé sur ça :


    sur le site de microsoft (https://www.microsoft.com/licensing/...Software/EAEAS).

    Étonnant, non ?
    delphi avait une politique semblabe......

    ces entreprises aiment pas trop que leur produit soit affiché en mauvaise posture...

  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
    20 945
    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 : 20 945
    Points : 49 762
    Points
    49 762
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Grulim Voir le message
    Salut,

    Suite à cet article, je me demandais pourquoi il n'y avait pas plus de benchmark MS SQL Server vs ... et en cherchant un peu, je suis tombé sur ça :

    sur le site de microsoft (https://www.microsoft.com/licensing/...Software/EAEAS).

    Étonnant, non ?
    On a déjà discuté de cela à maintes reprises sur les forums... Ce genre de clause est en standard dans tous les contrats, mais n'a en fait qu'une valeur juridique très limitée, car les droits de l'homme qui sont une Loi suprême accordent la liberté d'expression de tout un chacun. Il est dommage que vous ne connaissiez pas les droits de l'homme et leur valeur juridique. C'est très intéressant et très important... notamment tout ce qui parle de liberté d'expression. Je vous renvoi a cet article qui en fait le point avec ses limites :
    https://justice.ooreka.fr/astuce/voi...ue%20ce%20soit.
    Autrement dit on est parfaitement libre de faire ce genre de benchmark, à condition d'être loyal et pas dans le dénigrement !

    Et je remarque que c'est le genre d'arguments que me sortent systématiquement les ayatollah du libre pour me mettre en garde de na pas publier mes benchmarks.......


    Pourtant, ni le GIGN, ni le SWAT, ni le RAID ni la gendarmerie et même pas la police municipale ne sont venue me trouver chez moi pour me placer en prison sous prétexte d'un benchmark illicite....
    Et comme j'en ai publié pas mal...
    2011 : https://blog.developpez.com/sqlpro/p...alles_en_sql_1
    2017 : https://g-ernaelsten.developpez.com/...-performances/
    et aussi en 2016 : https://blog.developpez.com/sqlpro/p...omment-biaiser

    Comme d'autres l'on fait, par exemple Stéphane Faroult dans ses livres "The Art of SQL" et "Refactoring SQL Applications"...

    Mais peut être, personnellement, avez vous peur, êtes vous terrorisé, à la simple idée de vous servir de vos droits d'expression et publier de tels benchmarks ?

    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/ * * * * *

  8. #8
    Membre actif Avatar de Grulim
    Profil pro
    Inscrit en
    juillet 2004
    Messages
    234
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2004
    Messages : 234
    Points : 281
    Points
    281
    Par défaut
    Bonsoir,

    Je ne sais pas si la réponse de SQL-Pro s'adresse à moi, mais si c'est le cas, mon message n'avait pas pour but de vous discréditer ou de diminuer la valeur votre benchmark.

    Je me suis juste étonné du manque de comparatifs chiffrés des performances entre les différents SGBD, et je trouve ça dommage.

    Pour revenir sur MSSQL, le seul site important que je connaisse et que j'utilise est stackoverflow, preuve s'il en est que MSSQL peut être (très) performant. Il faut dire aussi que ce site emploie des pointures comme Marc Gravell.

    Cordialement.

    PS
    Et je remarque que c'est le genre d'arguments que me sortent systématiquement les ayatollah du libre pour me mettre en garde de na pas publier mes benchmarks.......
    Pourtant, ni le GIGN, ni le SWAT, ni le RAID ni la gendarmerie et même pas la police municipale ne sont venue me trouvé chez moi pour me placer en prison sous prétexte d'un benchmark illicite....
    Mais peut être, personnellement, avez vous peur, êtes vous terrorisé, à la simple idée de vous servir de vos droits d'expression et publier de tels benchmarks ?
    Je trouve ce genre de remarques déplacées, un peu too much, peut-on s'en tenir aux faits et discuter de manière plus constructive ?

  9. #9
    Membre régulier
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2008
    Messages : 22
    Points : 80
    Points
    80
    Par défaut
    Bonjour,

    Comme l'auteur de ce bench ne daigne pas en parler ici de ce qu'il ressort sur le forum postgresql.fr, je mets un lien vers la "discussion": https://forums.postgresql.fr/viewtopic.php?id=5931.

    Outre le fait que PostgreSQL s'en sorte mieux sous Linux, le benchmark réalisé par SqlPro démontre encore une fois sa mauvaise connaissance de PostgreSQL : REINDEX inutile après VACUUM FULL, paramétrage pas optimal sur les opérations de maintenance (maintenance_work_mem, maintenance_parallel_worker), et quand un résultat ne lui convient pas, c'est qu'on n'a pas bien fait le test.

    Enfin, à l'attention toute spéciale de SqlPro (ben quoi, je peux l'écrire comme ça, il n'y a pas de trademark), la lecture de cette page va s'avérer très intéressante : https://www.postgresql.org/about/policies/trademarks/.
    Thomas Reiss

  10. #10
    Membre éclairé
    Homme Profil pro
    Inscrit en
    février 2006
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations forums :
    Inscription : février 2006
    Messages : 557
    Points : 841
    Points
    841
    Par défaut
    Citation Envoyé par Grulim Voir le message
    Je trouve ce genre de remarques déplacées, un peu too much, peut-on s'en tenir aux faits et discuter de manière plus constructive ?
    Vous avez l'air étonné ? N'avez-vous jamais lu les commentaires de SQLPro ?

  11. #11
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 945
    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 : 20 945
    Points : 49 762
    Points
    49 762
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par frost242 Voir le message
    Bonjour,

    Comme l'auteur de ce bench ne daigne pas en parler ici de ce qu'il ressort sur le forum postgresql.fr, je mets un lien vers la "discussion": https://forums.postgresql.fr/viewtopic.php?id=5931.
    Excusez moi d'intervenir, mais vous postez sur PostGreSQL alors que l'article original est sur le site de developpez.com avec une entrée de forum qui lui est associé... C'est donc vous qui ne respectez pas les usages, et je trouve assez navrant que vous m'en fassiez porter le chapeau...

    Encore une fois, vous affirmez
    Citation Envoyé par frost242 Voir le message
    "Outre le fait que PostgreSQL s'en sorte mieux sous Linux,"
    Sans avoir jamais démontré ce fait... Ni sur l'enfilade que vous avez suscité sur les forums PostGreSQL ni dans le présent forum. Lorsque l'on affirme quelques chose d'aussi important on le prouve.
    Moi par exemple j'ai fait l'effort de démontrer que SQL Server sous Linux marchait un peu mieux (pas de beaucoup) sous Linux que sous Windows, avec des machines physiques strictement identiques.
    Lisez les tests que nous avons fait avec mon collègue Arian papillon
    https://blog.developpez.com/sqlpro/p...nux-vs-windows

    Qui est donc de mauvaise foi ?

    Vous affirmez encore aussi :
    ... encore une fois sa mauvaise connaissance de PostgreSQL : REINDEX inutile après VACUUM FULL,
    Je vous ai répondu que rien dans la doc n'indiquait cela et qu'il fallait les deux pour être équivalent à la même commande dans SQL Server, parce que les statistiques doivent aussi être recalculées...
    Et j'ai tendance à croire plus la doc officielle de PostGreSQL que vous...
    Ce que j'ai mentionné dans ma réponse à votre post :
    https://forums.postgresql.fr/viewtop...d=31978#p31978
    Que je recopie de peur d'être censuré

    "
    Cependant... VACUUM FULL ne fait pas la même chose que REINDEX TABLE... ou alors c'est que la doc est catastrophique dans ses explications...
    En effet, VACUUM FULL ne fait que retirer les lignes fantômes, tandis que REINDEX répare la fragmentation.
    1) Nulle part il n'est fait mention de la défragmentation d'index (appelés "bloat" dans PostGreSQL) dans la doc du VACUUM.
    2) nulle part il n'est fait mention de la suppression des lignes fantômes (appelées "dead tuples" dans PostGreSQL) dans la doc de REINDEX
    Je persiste donc à dire qu'il faut faire les deux ! Et que cela correspond exactement au ALTER TABLE ... REBUILD / ALTER INDEX ALL ... REBUILD de SQL Server qui reconstruit la table, ses index et recalcule les statistiques.
    "


    Vous m'attaquez ensuite parce que j'aurais fait un mauvais paramétrage....
    paramétrage pas optimal sur les opérations de maintenance (maintenance_work_mem, maintenance_parallel_worker), et quand un résultat ne lui convient pas, c'est qu'on n'a pas bien fait le test.
    Je suis loin d'être parfait j'en convient.... Mais lorsque l'on tente de donner des leçons il faut aussi être irréprochable.... On sait très peu de choses sur le paramétrage de votre instance SQL Server et certains réglages sont mauvais (dimensionnement du stockage, parallélisme...). Je vous l'ai dit dans les différents posts sur le forum PG en réponse à vos commentaires... En particulier un parallélisme de 8 est quelque peu différent d'un parallélisme de 48 !

    Citation Envoyé par frost242 Voir le message
    Enfin, à l'attention toute spéciale de SqlPro (ben quoi, je peux l'écrire comme ça, il n'y a pas de trademark), la lecture de cette page va s'avérer très intéressante :
    https://www.postgresql.org/about/policies/trademarks/.
    Très intéressant, mais a aucun moment il n'est fait référence à la notion de case dans le nom de PostGreSQL !

    Maintenant je note dans votre post sur le forum postgresql.fr du 5/2/21 19h05 (je vous cite) :
    Sur la notion de bench "SQL-Server vs PG-SQL" ça ne m'intéresse pas.
    Donc, je ne voit pas l'intérêt de polémiquer et surtout de vous répondre si cela ne vous intéresse pas et je ne comprends pas le masochisme que vous avez à ergoter sur des détails, si vous vous en foutez !

    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/ * * * * *

  12. #12
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 945
    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 : 20 945
    Points : 49 762
    Points
    49 762
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Grulim Voir le message
    Bonsoir,

    Je ne sais pas si la réponse de SQL-Pro s'adresse à moi...
    Pas directement.... mais vous soulevez un argument que les intégristes du libre m'envoie dans la gueule systématiquement afin d'essayer de discréditer...

    Citation Envoyé par Grulim Voir le message
    Je me suis juste étonné du manque de comparatifs chiffrés des performances entre les différents SGBD, et je trouve ça dommage.
    J'en ai fait pas mal ! Voir mon blog, tapez benchmark

    Et il y a ceux officiels de l'organisme TPC dans lequel PostGreSQL n'a jamais daigné publier...
    Notamment TCP.C (obsolète mais maintenu pour Oracle) et TPC.E (actuel)

    Citation Envoyé par Grulim Voir le message
    Pour revenir sur MSSQL, le seul site important que je connaisse et que j'utilise est stackoverflow, preuve s'il en est que MSSQL peut être (très) performant. Il faut dire aussi que ce site emploie des pointures comme Marc Gravell.
    et stackexchange, serverfault (en fait 176 sites...)
    Mais vous en connaissez sans doute beaucoup d'autres comme :
    • CDiscount
    • fnac.com
    • veepe (anciennement vente privées)
    • ...


    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/ * * * * *

  13. #13
    Membre régulier
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2008
    Messages : 22
    Points : 80
    Points
    80
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Maintenant je note dans votre post sur le forum postgresql.fr du 5/2/21 19h05 (je vous cite) :

    Donc, je ne voit pas l'intérêt de polémiquer et surtout de vous répondre si cela ne vous intéresse pas et je ne comprends pas le masochisme que vous avez à ergoter sur des détails, si vous vous en foutez !

    A +
    Ce n'est pas moi qui ait écrit cela, relisez un peu. En quoi qu'il en soit, ce qui ne m'intéresse pas, c'est de polémiquer avec vous. C'est votre spécialité, vous adorez ça et perdre votre temps là-dessus. Moi non, j'ai donné ce lien ici pour que les participants de ce forum puissent se rendre compte de la différence des temps de réponse de votre test, mais cette fois sous Linux.
    Thomas Reiss

  14. #14
    Membre averti
    Homme Profil pro
    R&D
    Inscrit en
    avril 2004
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : R&D

    Informations forums :
    Inscription : avril 2004
    Messages : 127
    Points : 406
    Points
    406
    Par défaut
    Bonjour Frédéric et merci pour cette étude certainement utile.
    quelques points à ajuster (ce n'est pas la critique)
    - Postgres sous Windows n'est pas considéré comme SGBD de production. En effet l’implémentation sous Windows est loin d'être optimale selon les développeurs qui préfèrent ce concentrer sur Linux
    - les fonctionnalités de Postgres sont en retard de 15 ans environ par rapport de SQL Server
    - l'optimiseur Postgres est toujours loin d'être parfait (c'est normale car ça coûte chère le moteur, des centaines et des milliers des homme-ans), il y a plusieurs exemples sur Internet. Par exemple, la prédiction sur les requêtes avec plusieurs JOINs est pourrie. Pas de stats automatiques. Perso, j'ai rencontré des situations quand la même requête sur les tables correctement indexées sous Postgres a été moins performante que celle de SQL Server sur les tables "heap" n'ayant aucun indexation !
    - l'index cluster Postgres (pas celui read-only), t'es où...
    - case insensitive/accent insesitive - l'implementation est toujours avec UPPER
    - pas de requêtes entre databases
    - la parallélisation de plans d’exécutions a débuté réellement dans v.12; il y a plusieurs limitations (c'est noté dans le doc Postgres)
    - le support multi-SGDB coté application: Postgres produit de souci sur rien, i.e. concaténation de valeurs varchar(2) et varchar(3) produit "text" à la place de varchar(5); il faut caster explicitement les valeurs "money" pour les comparer avec des constant de type integer et encore plusieurs trucs de ce genre
    - les outils de profiling par rapport de SQL Server sont très basiques (principalement, l'étude de logs), même chose pour pgAdmin vs SSMS
    - le backup/restore et l'export/import sont les mêmes notions pour Postgres ! La "sauvegarde" (SQL dump custom format) d'une BDD Postgres de 100 Go sur le serveur puissante prend presque 1/2 heure contre 2-3 minutes pour SQL Server (format binaire interne)!
    - encore plusieurs points qui requis sans doute une article pour décrire
    Bref, les avantages Postgres sont la "gratuité" (mais pour le support et la migration continue il faut payer aux distributeurs souvent encore plus que à Microsoft/partners) et le "job security"
    Bonne continuation

  15. #15
    Membre régulier
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2008
    Messages : 22
    Points : 80
    Points
    80
    Par défaut
    Bonjour,

    Citation Envoyé par Serguei_TARASSOV Voir le message
    - pas de requêtes entre databases
    Cette extension devrait vous intéresser : "postgres_fdw". Mais en effet, cela n'est pas possible sans passer par une extension et ne le sera jamais par un autre biais.

    Citation Envoyé par Serguei_TARASSOV Voir le message
    - les outils de profiling par rapport de SQL Server sont très basiques (principalement, l'étude de logs), même chose pour pgAdmin vs SSMS
    Avez-vous testé "PoWA" ?

    Cordialement
    Thomas Reiss

  16. #16
    Membre régulier
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2008
    Messages : 22
    Points : 80
    Points
    80
    Par défaut
    Rebonjour,

    Je reprends à tête reposée les points que j'ai laissé passé vendredi.
    Citation Envoyé par Serguei_TARASSOV Voir le message
    - Postgres sous Windows n'est pas considéré comme SGBD de production. En effet l’implémentation sous Windows est loin d'être optimale selon les développeurs qui préfèrent ce concentrer sur Linux
    Très juste.

    Citation Envoyé par Serguei_TARASSOV Voir le message
    - case insensitive/accent insesitive - l'implementation est toujours avec UPPER
    C'est possible, à condition de jouer avec de nouvelles collations.

    Citation Envoyé par Serguei_TARASSOV Voir le message
    - le backup/restore et l'export/import sont les mêmes notions pour Postgres ! La "sauvegarde" (SQL dump custom format) d'une BDD Postgres de 100 Go sur le serveur puissante prend presque 1/2 heure contre 2-3 minutes pour SQL Server (format binaire interne)!
    Vous ne maîtrisez pas bien le sujet côté Postgres. Il y a 3 façons de faire des sauvegardes et de restaurer : export/import; sauvegarde à froid (aucun intérêt de nos jours); sauvegarde PITR à chaud + restore PITR. Voyez par exemple l'outil pg_basebackup fournit avec PostgreSQL. Vous avez des outils plus avancés pour gérer les sauvegardes et restauration PITR: pg_backrest, pg_probackup, pitrery, etc.
    Thomas Reiss

  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
    20 945
    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 : 20 945
    Points : 49 762
    Points
    49 762
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Serguei_TARASSOV Voir le message
    Bonjour Frédéric et merci pour cette étude certainement utile.
    quelques points à ajuster (ce n'est pas la critique)
    - Postgres sous Windows n'est pas considéré comme SGBD de production. En effet l’implémentation sous Windows est loin d'être optimale selon les développeurs qui préfèrent ce concentrer sur Linux
    - les fonctionnalités de Postgres sont en retard de 15 ans environ par rapport de SQL Server
    - l'optimiseur Postgres est toujours loin d'être parfait (c'est normale car ça coûte chère le moteur, des centaines et des milliers des homme-ans), il y a plusieurs exemples sur Internet. Par exemple, la prédiction sur les requêtes avec plusieurs JOINs est pourrie. Pas de stats automatiques. Perso, j'ai rencontré des situations quand la même requête sur les tables correctement indexées sous Postgres a été moins performante que celle de SQL Server sur les tables "heap" n'ayant aucun indexation !
    - l'index cluster Postgres (pas celui read-only), t'es où...
    - case insensitive/accent insesitive - l'implementation est toujours avec UPPER
    - pas de requêtes entre databases
    - la parallélisation de plans d’exécutions a débuté réellement dans v.12; il y a plusieurs limitations (c'est noté dans le doc Postgres)
    - le support multi-SGDB coté application: Postgres produit de souci sur rien, i.e. concaténation de valeurs varchar(2) et varchar(3) produit "text" à la place de varchar(5); il faut caster explicitement les valeurs "money" pour les comparer avec des constant de type integer et encore plusieurs trucs de ce genre
    - les outils de profiling par rapport de SQL Server sont très basiques (principalement, l'étude de logs), même chose pour pgAdmin vs SSMS
    - le backup/restore et l'export/import sont les mêmes notions pour Postgres ! La "sauvegarde" (SQL dump custom format) d'une BDD Postgres de 100 Go sur le serveur puissante prend presque 1/2 heure contre 2-3 minutes pour SQL Server (format binaire interne)!
    - encore plusieurs points qui requis sans doute une article pour décrire
    Bref, les avantages Postgres sont la "gratuité" (mais pour le support et la migration continue il faut payer aux distributeurs souvent encore plus que à Microsoft/partners) et le "job security"
    Bonne continuation
    Vous avez parfaitement raison et c'est ce que je me tue à démontrer et qui a causé des dégâts dans certaines boites... Croire que PostGreSQL est aussi bon que SQL Server est une vaste fumisterie tant ses bugs et errement fonctionnels sont nombreux. Vous parliez des transtypages, mais il y a pire. J'en reparlerais dans le chapitre 3 de mes papiers comparatifs entre SQL Server et PostGreSQL.

    Curieusement, vous dites:
    Postgres sous Windows n'est pas considéré comme SGBD de production. En effet l’implémentation sous Windows est loin d'être optimale selon les développeurs qui préfèrent ce concentrer sur Linux
    Ce qui semble vrai pour les développeurs accros de Linux est beaucoup moins vrai dans l'entreprise. Dans les grandes entreprises on voit souvent du PostGreSQL sous Windows, lorsque le SI vient plus du monde Microsoft que du monde "free"...
    Et effectivement, dès que l'on veut du service ça coute très cher vu la pauvreté des outils comparés à SQL Server.... Il faut tout faire à la main dans PostGreSQL dès que l'on veut investiguer quand quelque chose marche mal.

    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/ * * * * *

  18. #18
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 945
    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 : 20 945
    Points : 49 762
    Points
    49 762
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par frost242 Voir le message
    C'est possible, à condition de jouer avec de nouvelles collations.
    Les nouvelles collations ICU sont buguées et ne permettent pas de faire du LIKE par exemple.... Imaginez de devoir récrire votre appli parce que les recherches avec LIKE pètent avec un message :
    ERROR: nondeterministic collations are not supported for LIKE
    Je n'ai jamais compris ce qu'une collation non déterministe peut vouloir dire étant donné qu'une collation est une surjection au sens mathématique du terme !
    Sans parler des corruption d'index engendrées par les collations "normales" :
    https://www.cybertec-postgresql.com/...ta-corruption/
    Bref, les collations dans PostGreSQL c'est la peste ou le choléra !
    Vous ne maîtrisez pas bien le sujet côté Postgres. Il y a 3 façons de faire des sauvegardes et de restaurer : export/import; sauvegarde à froid (aucun intérêt de nos jours); sauvegarde PITR à chaud + restore PITR. Voyez par exemple l'outil pg_basebackup fournit avec PostgreSQL. Vous avez des outils plus avancés pour gérer les sauvegardes et restauration PITR: pg_backrest, pg_probackup, pitrery, etc.
    Mais toujours pas de sauvegardes binaires comme le fait SQL Server, ce qui permet d'aller très très vite !

    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/ * * * * *

  19. #19
    Membre averti
    Homme Profil pro
    R&D
    Inscrit en
    avril 2004
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : R&D

    Informations forums :
    Inscription : avril 2004
    Messages : 127
    Points : 406
    Points
    406
    Par défaut
    Citation Envoyé par frost242 Voir le message
    Rebonjour,
    Vous ne maîtrisez pas bien le sujet côté Postgres. Il y a 3 façons de faire des sauvegardes et de restaurer : export/import; sauvegarde à froid (aucun intérêt de nos jours); sauvegarde PITR à chaud + restore PITR. Voyez par exemple l'outil pg_basebackup fournit avec PostgreSQL. Vous avez des outils plus avancés pour gérer les sauvegardes et restauration PITR: pg_backrest, pg_probackup, pitrery, etc.
    Vous avez donné 1/ encore fois les noms d'extensions (pour la fonctionnalité "core") 2/ qui utilisent toujours le dump SQL
    Les fonctions backup/restore doivent imperativement faire la partie de SGBD même "in box".
    Apart du temps long des opérations, les outils standard pg_dump/pg_restore requis la MAJ de statistique après la restauration ! J'ai vu cela il y a 25 ans en SQL Server 6.x, pas serieux en 2021.
    pg_basebackup ne concerne que le cluster - encore fois une outil specifique qui fait la fonctionnalité de base ! La philosophie de microoutils UNIX n'est pas toujours bien pour tous les autres types de logiciels, surtout s'il doit être bien intégré.
    Ce "design évolutif" est normal pour le bazar de dév en open source. Mais c'est à vous d'en debrouiller "gratuitement".

  20. #20
    Membre extrêmement actif
    Profil pro
    Inscrit en
    juin 2010
    Messages
    764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 764
    Points : 897
    Points
    897
    Par défaut
    Question est-ce que les updates dans Postgres sont toujours aussi naze ? Il n'y a pas si longtemps un update copiait, supprimait et recréait une nouvelle ligne, est-ce toujours le cas ?

Discussions similaires

  1. Réponses: 0
    Dernier message: 09/05/2014, 18h57
  2. Réponses: 5
    Dernier message: 04/02/2010, 00h06

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