Vous n'êtes pas identifié(e).
Effectivement Pifor... mea culpa !!!
Bonjour,
je suis confronté à une erreur bizarre. Tantôt psql.exe reconnais le mot de passe associé au compte postgresql si je le lance avec runpsql.bat tout se passe bien :
C:\WINDOWS\system32>"C:\Program Files\PostgreSQL\16\scripts\runpsql.bat"
Server [localhost]:
Database [postgres]:
Port [5433]:
Username [postgres]:
Mot de passe pour l'utilisateur postgres :
psql (16.1)
Attention : l'encodage console (850) diffère de l'encodage Windows (1252).
Les caractères 8 bits peuvent ne pas fonctionner correctement.
Voir la section « Notes aux utilisateurs de Windows » de la page
référence de psql pour les détails.
Saisissez « help » pour l'aide.
postgres=#Si je le lance directement au niveau du répertoire "bin", le mot de passe n'est pas reconnu :
C:\Program Files\PostgreSQL\16\bin>psql.exe -p 5433 -U postgresql
Mot de passe pour l'utilisateur postgresql :
psql: erreur : la connexion au serveur sur « localhost » (::1), port 5433 a échoué : FATAL: authentification par mot de passe échouée pour l'utilisateur « postgresql »
C:\Program Files\PostgreSQL\16\bin>J'avoue ne pas comprendre....
Que se passe t-il ?
A +
Conclusion... Comme dirais un certain rjuju, me citant...
...
sqlpro a écrit :Bref, commencez par lire, apprendre, vous former à PostgreSQL...
Merci.
A +
J'aimerais bien avoir votre paramétrage d'instance SQL Server car quel chose me chiffonne:
SELECT name, value_in_use FROM sys.configurationsA +
...
Dans mon entreprise, nous avons les 3 grands SGBDR du marché : Oracle SQLServer et PostgreSQL.
Ils ont chacun leurs bon côtés, mais il faut avouer que d'un point de vue business, les coûts astronomiques en licences des SGBDR propriétaires sont un frein très important.
C'est pourquoi les SI se penchent de plus en plus vers PostgreSQL qui en plus de réduire de manière conséquente les coûts, permet d'avoir des performances au moins aussi bonnes que les autres. En plus la philosophie du monde du libre et de la communauté est franchement rafraîchissante comparée aux hotlines et autres système de ticketing des mastodontes.
Alors pourquoi votre entreprise n'est elle pas sur du tout PostGreSQL ? Pourquoi n'a t-elle pas abandonné Oracle et SQL Server ?
Mais il y a beaucoup de fonctionnalité que PG ne possède pas qui font souvent la différence...
Quand aux coût astronomiques, je pense que vous parlez d'Oracle... Une licence SQL Server pour faire un site web de commerce c'est quelques dizaines d'euros par mois en SPLA...
Quand à la philosophie, dans un monde économique, elle pèse peu (hélas...). Les entreprises préfèrent payer et avoir un service, plutôt que des discussions philosophiques ! Et on peut les comprendre !
A +
re bonjour,
Vos conditions de test appliquées à SQL Server divergent fortement de ce que j'ai donnée, et surtout, de la pratique. En effet, dans SQL Server, comme dans Oracle il est d'usage de dimensionner le stockage des données et du journal de transaction. Peut être ne le saviez vous pas ? Mais cela m'étonnerais vu que vous me dites que vous avez de l'Oracle et du SQL Server dans votre entreprise...
C'est pourquoi j'ai indiqué clairement dans l'article que la base avait été créée comme suit :
* fichier de données: 12 Gb ;
* fichier du journal de transaction : 8 Gb.
Votre script en free drive ne montre pas cela...
CREATE DATABASE test ON (NAME = test_ds, FILENAME = '/home/aegir/sqlserver/test_ds.dbf');
GOCela rejaillis immanquablement sur certains résultats, comme justement l'insertion depuis un fichier (BULK INSERT) ou l'insertion depuis une table (INSERT SELECT). Merci de refaire vos tests en appliquant de réglage ! Sans cela, l'autocroissance des fichiers (qui est à proscrire) va prendre du temps au détriment de l'opération...
Sur le VACUUM FULL, vous avez raison, mais le moins que l'on puisse dire c'est que la documentation n'est pas claire. Il faut lire toute la page pour s'en rendre compte.
1) l'entête de la doc précise au niveau du VACUUM FULL "rewrites the entire contents of the table" et donc ne parle pas des index.
2) Le paragraphe spécifique au VACUUM FULL indique que c'est la table qui est visée et ne parle pas des index...
Il faut aller lire l'entrée INDEX_CLEANUP pour vois que les index aussi sont pris en compte !
https://www.postgresql.org/docs/current/sql-vacuum.html
Bref, la documentation est à améliorer sérieusement !
J'avoue avoir raté ce point et je pense ne pas être le seul...
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 dites :
"Dans tous les cas, quand on vous dit que PostgreSQL est plus performance sous Linux, il serait peut-être temps de réaliser que ce n'est pas pour rien."
Mais il n'y a aucune démo de cela dans vos tests.... c'est de l'affirmation gratuite sans intérêt et c'est dommage de vous dévaloriser alors que vous menez des tests intéressants.
Vous avez raison sur le fait que la maintenance nécessite un "max_parallel_maintenance_workers" plus élevé que 2. Je referais mes tests avec un 48...
Bref, d'après vos résultats et si l'on enlève les deux insertions, PostGreSQL ne fait mieux que sur les recalculs de statistiques... Cependant, vous ne donnez pas la mesure de l'échantillon statistique utilisé par PG... Quel est-il ? Car là j'ai un sérieux doute sur la grandeur de l'échantillon.... Autrement dit cet échantillon est-il comparable en terme de pourcentage à celui de SQL Server ?
Enfin vos tests sont realisés sur un PC de bureau doté de 8 cœurs. Dans la réalité de l'exploitation des bases de données dans le monde de l'entreprise, il est rare, si l'on veut servir de nombreux utilisateurs et avoir des performances, d'être aussi limité. C'est pourquoi j'ai travaillé sur une machine à 24 cœurs physiques ce qui avec l'hyperthreading donne 48 coeurs exploitables par le SGBDR.
Si l'on divise alors les temps de réponse de SQL Server par un facteur approchant (48 / 8 = 6, mais je ne retiendrais que 5 de fait de la Loi d'Amdhal), alors, nous devrions retomber sur des différences aussi significatives que celles que j'ai donné dans mon article initial...
Test SQL Server pondéré // PostGreSQL Gain (SQL Server)
---------------------------|--------------------------|-----------|--------------------
rebuild / Vacuum + reindex : 13 447 ms / 5 = 2 689 ms | 24 364 ms | 9 fois plus rapide
CREATE INDEX X_1 : 7 122 ms / 5 = 1 424 ms | 12 038 ms | 8 fois plus rapide
CREATE INDEX X_2 : 7 105 ms / 5 = 1 421 ms | 11 792 ms | 8 fois plus rapide
CREATE INDEX X_3 : 14 236 ms / 5 = 2 847 ms | 19 126 ms | 7 fois plus rapide
TBL REBUILD / VACUUM FULL : 13 925 ms / 5 = 2 785 ms | 56 014 ms | 20 fois plus rapide
INDEX REBUILD / REINDEX : 21 529 ms / 5 = 4 306 ms | 48 183 ms | 11 fois plus rapide
UPDATE STATS X1 / ANALYZE : 411 ms / 5 = 82 ms | 149 ms | 2 fois plus rapide
UPDATE STATS X2 / ANALYZE : 512 ms / 5 = 102 ms | 171 ms | 2 fois plus rapide
sp_updatestats / ANALYZE : 382 ms / 5 = 76 ms | 508 ms | 7 fois plus rapideMais il ne s'agit là que d'une extrapolation !
A +
...
Avez-vous, pour votre benchmark, positionné les paramètres "shared_memory_type" et "dynamic_shared_memory_type" à la valeur "windows" ?
Non, car cela est fait automatiquement dans l'installeur de PG 13 pour Windows. Donc ces deux paramètres ont bien la valeur "windows"
Avez-vous assigné le droit « Verrouiller les pages en mémoire » (Lock Pages in Memory) à l'utilisateur Windows qui fait tourner PostgreSQL ?
Ce paramètre est très controversé. En tant que membre d'un groupe d'expert Microsoft SQL Server, nous ne recommandons pas ce paramétrage qui n'a pas d'influence significative au niveau des performances et possède de gros risques. Il n'est donc activé pour aucun process que ce soit PostGreSQL ou SQL Server...
Il faut penser à mettre une valeur de max_wal_size suffisante, par rapport à shared_buffers, pour (dixit la doc) : étendre dans le temps les écritures de grandes quantités de données, nouvelles ou modifiées.
max_wal_size est à 1 Go (1024 MB). Je n'ai pas réglé ce paramètre, pour PostGreSQL. En le passant à 10 Go et en le testant sur différentes requêtes, je n'ai vu aucune différence ce qui est bien normal car les écritures des CHECKPOINT sont asynchrones...
Peut être faudrait-il régler les min_wal_size qui est actuellement de 80 Mo...
Si j'ai le temps, je referais vos benchmarks sur un linux, même si je n'aurais pas une machine avec 128G de ram tout de suite à disposition et que ce sera plutôt du PGS11.
Volontiers mais pensez à les publier sur developpez.com puisque l'article original est sur ce média...
A +
Comment voulez vous retrouver la première ligne dans un système ensembliste si l'on y met pas un peu d'ordre ?
Certes il n'y a pas de ORDER BY (tri logique), mais il effectue un tri interne (physique) d'une quelconque manière (accès à la PREMIÈRE ligne de la page) pour retrouver l'information...
A +
Ben déjà c'est comparer des choux et des carottes, à moins que ça ait changé, en Sybase le BULK INSERT / BCP désactive par défaut les contraintes de la table. C'est pas les mêmes fonctionnements.
Tout d'abord Sybase et SQL Server sont deux produits différents. Plus de 30 ans de différence. PostGreSQL n'étais pas encore né, lorsque Microsoft a divergé de son achat de Sybase.
Mais vous avez partiellement raison sur ce point, cependant vous omettez de dire que la désactivation des contraintes de table ne concerne que :
1) les contraintes CHECK
2) les contraintes FOREIGN KEY
Les tables de notre tests n'ayant ni l'une ni l'autre, votre argument est donc NULL et non avenu !... Serait-ce du dénigrement ???
Autre exemple qu'on est dans la comparaison choux/carottes : Le gestion de l'isolation des transactions par défaut n'est pas du tout la même (verrouillage partagé/exclusif de pages par défaut en Sybase). ... bla bla bla ...
Ce dont vous parlez n'a aucun rapport et aucun intérêt avec les tests effectués dans cet article :
https://sqlpro.developpez.com/tutoriel/ … -pour-dba/
En effet :
1) Il n'y a aucune transaction explicite et aucun lot de plusieurs commandes passées simultanément. Donc votre démo ne sert a rien qu'a embrouiller les lecteurs;
2) Sybase n'est pas SQL Server... 30 ans de R&D d'écart. Comme si je disais PostGreSQL = Ingres !
3) SQL Server peut fairt du verrouillage optimiste de la même manière que Oracle ou PostGreSQL. C'est même conseillé dans la plupart des cas de figure !
Bref, commencez par lire, apprendre, vous former à SQL Server...
Mes sites :
https://sqlpro.developpez.com/
http://mssqlserver.fr/
Comme mon bouquin :
https://www.amazon.fr/SQL-Server-2014-a … 2212135920
peuvent vous y aider !
A +
Bonjour,
Bonjour SQLpro,
Merci pour votre article très intéressant qui montre que SQLserver est un SGBDR performant parmi les meilleurs des SGBDR propriétaires, il ne faut pas douter de ça.
Par contre je trouve que votre comparaison avec PostgreSQL est un peu biaisée par plusieurs choses :
- PostgreSQL fonctionne moins bien sur un serveur windows à cause de la gestion mémoire de cet OS (contrairement à sqlserver qui est optimisé pour cet OS). Il aurait fallu faire la comparaison SQLServer/windows, PostgreSQL/linux (ou pourquoi pas une comparaison sqlserver/linux vs postgresql/linux ?).
je vous en prie, faites la preuve de ce que vous avancez. Pour ma part je n'ai jamais vu de différence significative à ce niveau... Vous avez tous les fichiers à votre disposition. Ayez le courage de me contredire avec des faits et non des mots. J'ai rarement vu un écart de plus de 8% sur quelques requêtes... Rien de plus !
- la configuration PostgreSQL que vous appliquez aurait mérité un peu de parallélisme en configurant des parallel_workers
- en version 13, la vacuum des index est parallélisable.
Aucune des requêtes que j'ai fait n'a montré dans son plan le moindre parallélisme en aucune manière. Raison pour laquelle je n'ai pas mentionné ce paramétrage que j'ai mis à 48 !
Le plan de requête de VACUUM n'est pas disponible contrairement à SQL Server qui permet de visualiser les plans de toutes les commandes... Mais si vous me dite qu'il a parallélisé, avec 48 cœurs de limite, alors c'est pathétique d'avoir un résultat de 30 fois plus lent... !
Pour les commandes COPY, soyons indulgents avec postgresql : le moteur est encore jeune et toujours en cours d'amélioration, le parallélisme des processus de COPY arrive prochainement.
C'est une bonne chose !
Et puis je suis sûr que si on creuse un peu, on trouverait des commandes SQL qui seraient plus rapides dans postgresql que dans sqlserver ;-) non ?
Oui, je vais publier d'autres articles, car c'est une série, et dans certains commandes PostGreSQL s'est révélé meilleur que SQL Server; ça reste néanmoins assez rare.
Là ou c'est le plus significatif c'est sur le spatial. Franchement 1/3 des requêtes PG sont plus rapide que SQL Server dans le benchmark qque j'avais effectué et qui mériterait d'être rafraichit avec les dernières version de deux SGBDR :
https://g-ernaelsten.developpez.com/tut … formances/
A +
LIMIT 1 impose un tri. Or les index GIN ne sont pas "triables"
A +
Bonjour,
premier d'une longue série d'article sur le sujet, un comparatif entre SQL Server et PostGreSQL au sujet des performances des requêtes pour le DBA :
https://www.developpez.net/forums/d2101 … andes-dba/
Vos commentaires sont les bienvenus
A +
La solution de rajouter artificiellement une super clef à la clef naturelle de jointure n'a d'intérêt que si vous avez des tables filles faisant référence à cette table de jointure. Dans tous les autres cas, je vous confirme les propos de rjuju, surtout une volumétrie accrue, la chute de performance en n'étant problématique que pour les mises à jour, pas pour les SELECT.
A +
Le problème est que la compression systématique des LOBs avec TOAST joue en votre défaveur sur les données spatiales, car le contenu des données spatiale est assez aléatoire ce qui fait que le volume augmente légèrement au lieu de diminuer. Et il n'y a aucun moyen de désactiver TOAST, à moins de recoder le moteur PostgreSQL… (vous pouvez le faire!!!).
De plus PostgreSQL ne supporte pas la compression des données des tables et des index que l'on trouve dans d'autres SGBDR comme Microsoft SQL Server… ce qui permettrait de réduire considérablement le volume des autres données purement relationnelles.
Bref, PostgreSQL c'est double peine ! Compression obligatoire des LOBs, parfois inutile et contre-performantes pour certaines données, et impossibilité de compresser les autres données !
A +
Si tel est le cas votre modèle est mal fait. En effet ce que vous indiquez correspond à une association de type 1 à 1 dans un MCD, comme :
Homme <--> (marié) <--> femme
Dans un tel cas, le MPD correspondant est le suivant :
CREATE TABLE A (A_ID INT PRIMARY KEY, A_LIBELLE VARCHAR(32));
CREATE TABLE B (B_ID INT PRIMARY KEY, B_LIBELLE VARCHAR(32), A_ID INT REFERENCES A (A_ID));
ALTER TABLE A ADD B_ID INT REFERENCES B (B_ID);Avec en sus 2 déclencheurs obligeant les couples A_ID et B_ID des deux tables d'avoir une correspondances absolue.
A +
Bonjour,
La CAF vient de migrer ses bases PostgreSQL sous Oracle en cloud, réduisant ainsi quelques 150 bases (et presque autant de serveur) à une seule base, de manière, notamment, à réduire ses coûts…
A +
Bonjour à tous.
J'ai sauvegardé une base PG v 9.6.1 (64 bits sous Windows 10 pro) via la commande :
"C:\Program Files\PostgreSQL\9.6\bin\pg_dump.exe" --host localhost --port 5432 --username postgres --blobs --format=d -f "C:\SAVE_DB\DB_GEOPG.BAK" DB_GEOCeci a produit un fichier contenant les commandes SQL CREATE/INSERT.
La base a été supprimée.
Je n'arrive pas à restaurer malgré différents essais avec différentes syntaxes. Par exemple celle-ci :
"C:\Program Files\PostgreSQL\9.6\bin\pg_restore.exe" --host localhost --port 5432 --username postgres -f "C:\SAVE_DB\DB_GEOPG.BAK"Ne fais rien, mais ne termine pas la commande....
Auriez vous un idée de la manière qu'il faut s'y prendre pour restaurer une base ?
D'avance merci
De toutes façons, PostGreSQL est encore très loin des standards en matière de collation. Voici une base créée avec la collation "French.France.1252" (qui est en fait un jeu de caractères et pas vraiment une collation). Démonstration :
CREATE TABLE T_MOT (MOT VARCHAR(32));
INSERT INTO T_MOT VALUES ('Retraite'), ('retraite'), ('retraité'), ('Retraité'), ('RETRAITÉ'), ('RETRAITE');
SELECT * FROM T_MOT ORDER BY MOT;Résultat :
"retraite"
"Retraite"
"RETRAITE"
"retraité"
"Retraité"
"RETRAITÉ"
Or la règle en français est de placer les mots accentués avant les mots sans accents...
Le mot clef COLLATE est très mal supporté et la documentation est plus que obscure... Impossible de savoir quelle combinaison de jeux de caractères / collation il faut pour pouvoir :
* faire indifféremment des recherches sensibles ou non à la casse (indépendamment des accents et autres caractères diacritiques)
* faire indifféremment des recherches sensibles ou non aux caractères diacritiques (indépendamment de la casse)
Un cas pertinent est de pouvoir trouver le mot "maïs" sans obtenir le mot "mais" quelque soit la casse.
INSERT INTO T_MOT VALUES ('maïs'), ('MAÏS'), ('Maïs'), ('Mais'), ('mais'), ('MAIS');
SELECT * FROM T_MOT WHERE MOT = 'maïs';Il reste la solution de faire un LOWER, mais cela ne devient plus "sargable" donc les performances sont en chute libre !
A +
Un moyen d'accélérer le traitement d'import est de saucissonner vos fichiers pour que vous n'ayez pas d'opération d'écriture physique avant la fin de le mise en cache de l'intégralité des données du fichier.
Essayez avec des fichiers de moins de shared_buffer / 3
Le second moyen est de placer le journal qui est écrit de manière synchrone sur un RAID multiplexé (10 ou 0+1) en jouant sur le nombre de disque (par exemple 8 disque en //). Ceci devrait nettement améliorer le débit transactionnel.
Assurez vous cependant que votre carte RAID supporte la parallélisation des accès et le load balancing...
Par exemple les cartes bas de gamme livré par DEL (PERC H700 et PERC 6/I) ne savent ni faire du parallélisme ni du load balancing...
En particulier, la gamme de serveur Dell PowerEdge R210 n'est absolument pas adaptée aux serveurs de type SGBDR si l'on veut obtenir des performances. Le controleur interne ne sait faire que du RAID 5 / 6 et toutes combinaisons (50/60), ce qui pénalise les opérations de journalisation, d’où une contention importante.
A +
Le problème vient du fait que vous faites du décisionnel sur un serveur de bases de données relationnel (ROLAP). Or dans ce cas, la plupart du temps, il faudra lire séquentiellement l'intégralité des lignes des tables en jeu. Il vous faut donc une RAM au moins équivalent à la plus grande table, voire à la base entière si jointure il y a...
Le mieux serait d'avoir un véritable moteur décisionnel, car ces derniers ne stockent pas les données de la même façon, afin d'accélérer les manipulations :
1) il y a compression des données (contrairement aux bases relationnelles ou cela couterait trop cher du fait des mises à jour incessantes)
2) le NULL n'est pas stocké (contrairement aux bases relationnel ou le changement d'état d'une donnée est courante, passant du NULL à une valeur)
3) certains agrégats sont pré-calculés afin de diminuer l'accès aux données (voir la règle 4 de Codd sur le décisionnel : "la rapidité d'extraction de l'information ne doit pas être dépendante du volume des données à traiter, mais du volume des données restituées")
4) certains SGBD Décisionnel font du cache de résultat en sus de la règle 3
Ces deux dernières règles n'ayant aucun intérêt dans un SGBD Relationnel, car l'état des informations changent tout le temps du fait des multiples transactions dans la journée, ce qui n'est pas le cas du décisionnel dans lequel on "statifie" les données.
Parmi les SGBD Décisionnel il y a :
* Terradata
* Oracle (BI Suite)
* SQL Server (SSAS/SSRS)
A +
Quand vous dites :
Cette version publique initiale ...
Voulez-vous dire qu'à l'avenir cela va devenir payant ?
A +
Tout simplement, postgres (comme la plupart des autres moteurs de données) ne vont pas bien gérer le stockage d'objets volumineux en base, car c'est n'est pas prévu pour. Vous pouvez cependant le faire, vous n'aurez aucun problème de fiabilité, juste portentiellement des problèmes de performances différents.
Au passage, le standard SQL/MED (et plus particulièrement la partie datalink, voir https://wiki.postgresql.org/wiki/DATALINK) permet de s'affranchir du problème en utilisant le stockage disque standard pour cela, avec le même principe que pour la base(ACID), mais très peu de moteurs l'implémentent (ce n'est pas le cas de postgres).
Désolé de vous contredire, mais la plupart des SGBD Relationnels comme Oracle ou SQL Server proposent une méthode identique ou similaire pour ce faire. Oracle avec BFile et SQL Server avec FILESTREAM (depuis le version 2005, soit 10 ans)...
A +
Il faut implémenter une série de déclencheurs dans chacune des tables fille en sus de l'intégrité référentielle traditionnelle. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/mode … /heritage/
A +
Effectivement ce sont les "round trips" c'est à dire les aller et retour entre serveur et client, autrement dit les temps réseau, qui bouffent (à vue de nez) 99,9% de votre temps de traitement...
Ceci n'est pas nouveau et c'est généralement lié au style de développement. Plus vous mettrez de code ensembliste côté serveur SGBDR plus les performances seront importante...
À me lire : http://img1.lemondeinformatique.fr/fich … aisses.pdf
A +