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
Discussion :
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 :
Bonne lectureCe 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.
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/ * * * * *
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.
- 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 ?
- Qu�est-ce qui justifie d�avoir une configuration sp�cifique pour PostgreSQL mais pas pour SQL Server ?
- 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)
- 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 ?
- 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.
- 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).
Bonjour,
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...).Envoy� par RenardSpatial
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...
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...
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...
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.
Mon exp�rience et les documents de r�f�rence suivant :
https://wiki.postgresql.org/wiki/Tun...tgreSQL_Server
https://pgtune.leopard.in.ua/#/
...
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...
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...
� 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.
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...)
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/ * * * * *
Salut,
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 :
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).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.
�tonnant, non ?
delphi avait une politique semblabe......
ces entreprises aiment pas trop que leur produit soit affich� en mauvaise posture...
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/ * * * * *
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....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 ?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 ?
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/.
Vous avez l'air �tonn� ? N'avez-vous jamais lu les commentaires de SQLPro ?
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
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 :
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...... encore une fois sa mauvaise connaissance de PostgreSQL : REINDEX inutile apr�s VACUUM FULL,
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....
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 !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.
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) :
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 !Sur la notion de bench "SQL-Server vs PG-SQL" �a ne m'int�resse pas.
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/ * * * * *
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...
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)
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/ * * * * *
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.
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
Bonjour,
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.
Avez-vous test� "PoWA" ?
Cordialement
Rebonjour,
Je reprends � t�te repos�e les points que j'ai laiss� pass� vendredi.
Tr�s juste.
C'est possible, � condition de jouer avec de nouvelles collations.
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 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:
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"...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
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/ * * * * *
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 !
Mais toujours pas de sauvegardes binaires comme le fait SQL Server, ce qui permet d'aller tr�s tr�s vite !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.
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/ * * * * *
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".
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 ?
R�pondre avec citation
Partager