Vous n'êtes pas identifié(e).
Bonsoir et merci pour ta réponse rjuju,
J'aurais plusieurs questions à poser du coup :
1. Pour le paramètre "shared_buffers" (qui est le "shared memory buffers" ou "mémoire partagée" en français) :
1.a. Qu'est-ce que ça contient et à quoi ça sert ?
1.b. Est-ce que c'est un cache qui retient une opération effectué par une personne X pour qu'une autre personne Y puisse en bénéficier s'il exécute une requête similaire à X ?
2. J'ai remarqué que pour Linux "shared_buffers + effective_cache_size" représente la taille total de la RAM. Pourquoi ne réserve-t-on pas un peu d'espace pour l'OS ?
3. Je n'ai pas compris le sens de "effective_cache_size". Qu'est-ce que ça contient et à quoi ça sert ?
4. Concernant "work_mem" : est-ce que 1 SELECT = 1 "work_mem", OU BIEN est-ce qu'il peut y avoir plusieurs "work_mem" pour 1 requête (ex: 1 "work_mem" pour le tri du SELECT, 1 "work_mem" pour la jointure etc) ?
5. J'ai vu que le "shared_buffers" était limité à 512MB pour Windows, est-ce que cela signifie que pour un même matériel (avec beaucoup de RAM), une instance de PostgreSQL sous Linux donnera de meilleures performances que sous Windows ?
6. D'après ce que j'ai compris en lisant la documentation, "wal_buffers" représente un morceau du WAL dans la RAM et "max_wal_size" la taille d'un WAL sur le disque :
6.a. Est-ce que je me trompe ?
6.b. Je suppose que si un crash survient sur le noeud master, le contenu du "wal_buffers" est perdu à jamais (vu que c'est en RAM), mais si c'est le noeud esclave qui meurt pendant l'envoi, est-ce que le noeud esclave pourra répliquer le noeud master après son redémarrage ? (je sais que cette question est un peu HS par rapport au benchmark ).
6.c. En quoi "max_wal_size" est un paramètre à prendre en compte dans le tuning si ce dernier représente juste un fichier sur le disque ?
7. A quoi sert "checkpoint_completion_target" ? Je n'ai pas compris son utilité.
Note 1: N'hésitez pas à revenir sur ce que je dis (surtout si je dis des bêtises...).
Note 2: La question "1." est en deux parties, la question "6." est en trois parties.
Un grand merci pour votre aide, cordialement,
Bonjour,
Je souhaiterais réaliser un nouveau benchmark bientôt, je n'ai jusqu'à présent pas changé la configuration par défaut, mais je ne souhaite pas que l'on me fasse des remarques du type : "nul, t'as même pas touché aux paramètres" etc...
=> Quelles sont les paramètres que vous me conseillez de modifier pour améliorer mon benchmark, et dans quel but ?
Je vous remercie par avance, cordialement,
Well, you're in a forum, so people don't really care if you do not have time.
I don't know what fuzzy is, but I think you should read this article : http://www.rdegges.com/easy-fuzzy-text- … ostgresql/
And use this instruction once :
CREATE EXTENSION pg_trgm;
... in order to import "fuzzy" functions
NB: And please, don't use Google Translate for french (that's just horrible).
Je viens de jeter un coup d'oeil dans la documentation, il semblerait que le partitionnement sous PostgreSQL ne soit pas encore disponible par rapport aux autres SGBD.
Il existe bien un partitionnement, mais "par héritage de table", malheureusement ça a l'air assez naze par rapport à la concurrence.
J'ai trouvé un draft ici : https://wiki.postgresql.org/wiki/Table_partitioning . Si vous avez des infos concernant une futur implémentation du partitionnement des tables sous PostgreSQL n'hésitez pas
Le partitionnement est une optimisation, n'hésite pas à consulter la documentation pour mieux saisir le principe.
J'ai dit UNION pour t'introduire à l'opérateur ensembliste, mais utilise plutôt UNION ALL pour ton besoin (ça sera moins lourd)
Bonjour,
En ayant lu votre problème je me suis arrêté sur plusieurs points, mais surtout celle-ci :
"Pour chaque semaine, j'ai 1 table" (cf : trans_log_y2015_w29, trans_log_y2015_w30, trans_log_y2015_w31)
Cela me rappelle une entreprise d'une chaine de restaurants (dont je ne citerais pas le nom) qui faisait de même pour gérer son SI. Ma question est : le partitionnement n'était t-il pas envisageable plutôt que de se casser la tête à créer 52 tables par an ?
Un NATURAL JOIN n'est rien d'autre qu'une syntaxe sucrée pour une jointure interne, pas une solution miracle. D'après la lecture de votre message, je dirais que vous cherchez à réaliser un UNION entre vos différentes tables.
PS: Pourquoi utiliser un nom de colonne identique qu'un type ? C'est comme appeler une colonne "entier" parce que son contenu est un entier.
D'accord,
Une version plus courte serait plus maintenable alors : SELECT field, sum(a) / NULLIF(sum(b), 0) FROM ma_table GROUP BY field;
Et sinon pour la question 2 des idées ?
Cordialement,
Merci pour ton retour Julien,
Je n'ai pas compris cette phrase : "La seule raison de faire un cas spécifique c'est si vous voulez autre chose que le comportement standard, par exemple diviser par 1 plutôt que renvoyer NULL.". Est-ce que c'était une réponse pour question 2. ?
Bonjour,
Lorsqu'on effectue une opération entre 2 NULL comme ici :
SELECT NULL / NULL;
ou
SELECT NULL + NULL;
... cela lance une exception de type 42725 ambiguous_function.
Selon vous, quelle est le meilleur moyen de gérer une division entre deux champs a et b, sachant que a et b peuvent être NULL, et b peut valoir 0 (donc 22012 division_by_zero).
J'ai pensé à ceci :
SELECT
field,
CASE WHEN SUM(b) IS NULL OR SUM(b) = 0 THEN NULL ELSE SUM(a) / SUM(b) END
FROM ma_table
GROUP BY field;
1. Qu'en pensez-vous ?
2. Est-ce que le fait d'utiliser SUM(b) 3 fois dans cette requête fait que le SGBD calcul 3 fois ce champs, ou est-t-il suffisamment "intelligent" pour ne le calculer qu'une seule fois ?
Merci, cordialement,
Après réflexion, je dois refaire les tests A1, A2 et A3 pour la partie concernant MySQL car je n'ai pas pris en compte le fait que ce dernier ne faisait pas d'autocommit pour les procédures...
Bonjour tout le monde,
Dans le cadre de mon projet de synthèse j'ai réalisé un benchmark PostgreSQL vs MySQL.
Si vous souhaitez y jeter un coup d'oeil : http://www.developpez.net/forums/blogs/ … -vs-mysql/
N'hésitez à pas me dire ce que vous en pensez ou comment on pourrait améliorer ce benchmark.
Cordialement,
J'ai installé PostgreSQL sur Windows, donc oui j'ai utilisé l'installeur d'EnterpriseDB.
J'ai suivi la même procédure pour l'installation de PostgreSQL 9.2 à l'époque mais il me semble que je n'avais pas rencontré ce cas.
Y a-t-il un problème avec le fait d'utiliser l'installeur ?
Cordialement,
Bonjour,
Je viens d'installer PostgreSQL 9.4.3, en allant dans le fichier postgresql.conf j'ai vu ceci :
listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
Je voulais mettre '*', mais c'était déjà '*', dans le commentaire on peut toujours lire "defaults to 'localhost'".
Existe-t-il un lien indiquant tous les paramètres et leurs valeurs par défaut des fichiers pg_hba.conf et postgresql.conf (pour chaque version de PostgreSQL) ?
Cordialement,
L'EXPLAIN ANALYZE est horriblement long, comment distinguer les 2 messages ? gleu ne l'a peut-être pas vu.
Bonjour Guillaume,
Merci pour vos réponses.
Tout dépend de ce que vous appelez WAL. Si vous parlez d'un segment de journal de transactions, alors non.
8. Un segment de journal de transaction fait 16 Mo, donc je me doute bien que le Master ne va envoyer un tel fichier à travers le réseau, cependant je me demande dans les cas du Synchronous Streaming Replication, quelle opération "technique" est réalisée lorsqu'on fait ceci sur le Master :
START TRANSACTION;
INSERT ...;
COMMIT;
----
Les esclaves sont créés à partir du maître. Les esclaves savent donc qu'ils sont esclaves.
9. Comment une machine sait qu'elle est Master ? Quel paramètre détermine cela ?
----
10.
A vous lire j'ai l'impression que (vrai/faux) :
a. la machine Master "A" de mon exemple (qui sera HS à un instant T) est destinée à être Master du cluster début à la fin si un humain ou programme ne résout pas le problème parce que les Slaves PostgreSQL (cf : les machines B, C et D de mon exemple) ne savent pas détecter le problème de "A" et agir en conséquence,
b. et que si "A" tombe HS les slaves (cf : les machines B, C et D de mon exemple) resteront slaves à vie,
c. et enfin qu'il faut forcément agir "manuellement" pour que le cluster PostgreSQL soit de nouveau opérationnel,
d. et que pour conclure même si la documentation parle de failover le cluster PostgreSQL lui ne gère aucun failover par lui-même,
... je me trompe ?
Si je me trompe, pourriez-vous me dire à quel niveau je dois agir pour automatiser au maximum le cluster ? Pour prouver que notre cluster PostgreSQL fonctionne, mon groupe devra éteindre le Master (cf : A), et nous aurions espéré que B, C ou D devienne automatiquement Master à son tour ! PostgreSQL ne gère pas cela automatiquement ? (d'où le terme de "négociation" dans le 1er message).
Merci encore, cordialement,
Bonjour,
Dans le cadre d’un projet universitaire, mon groupe souhaiterait mettre en place la réplication sur une grappe de machines avec PostgreSQL 9.3 installé sur chacune de ces machines (même configuration technique, même OS, même version de PostgreSQL).
L’objectif sera de mettre en place un cluster PostgreSQL (1 Master avec 3 Slaves), le cluster PostgreSQL devra se comporter de manière « autonome ».
Par « autonome » il faut comprendre :
• Si un Master meurt, un des Slaves prend automatiquement sa place.
• Un nouveau Slave intégré dans le cluster intègre les données existantes (récupère automatiquement les WAL).
Notes :
• On part du principe que chaque nœud PostgreSQL est susceptible de « tomber » (être Hors-Service) à un moment donné (câble Ethernet coupé, coup de pied dans le serveur etc), donc aucune machine n’est fiable à 100%.
• Nous n’utiliserons que les fonctionnalités de base proposée par PostgreSQL 9.3 (donc pas ajout d’extension du style Bucardo etc).
• Le contenu des fichiers de configuration (postgresql.conf, pg_hba.conf, recovery.conf) seront normalement identiques entre les 4 machines du cluster (sauf si vous m'indiquez une raison contraire).
Nous avons choisi le mode :
• Hot Standby : pour autoriser la lecture sur les Slaves (ou « Standby Server »).
• Synchronous Streaming Replication : pour que la réplication soit « immédiatement » prise en compte par les Slaves avec « accusé de réception » sur le Master.
Questions :
1. Demande de confirmation : Lorsqu’on utilise le Synchonous Streaming Replication, est-ce que le Master envoie 1 WAL pour 1 transaction réalisée en TCP ?
Voici un schéma qui résume les problématiques posées dans les questions 2. et 3. lorsqu'une machine Master A meurt et que les Slaves B, C et D dont le primary_conninfo contient l'addresse IP de A sont toujours en vie.
2. Lorsque l'on démarre les machines du cluster PostgreSQL, sur quel critère une machine devient Master et les autres Slaves ? Est-ce que la négociation entre les machines est « automatique » ? Faut-t-il utiliser une commande manuelle au démarrage du serveur (si oui laquelle) ?
3. Dans la documentation il est dit : « PostgreSQL does not provide the system software required to identify a failure on the primary and notify the standby database server. Many such tools exist and are well integrated with the operating system facilities required for successful failover, such as IP address migration. »
A quel moment un slave devient master ? Quel paramètre faut-t-il mettre en place pour ce processus soit automatique ?
4. Dans la documentation il est dit : « If the primary server fails and the standby server becomes the new primary, and then the old primary restarts, you must have a mechanism for informing the old primary that it is no longer the primary. This is sometimes known as STONITH (Shoot The Other Node In The Head), which is necessary to avoid situations where both systems think they are the primary, which will lead to confusion and ultimately data loss. »
Est-ce que ce mécanisme appelé STONITH est automatiquement géré par PostgreSQL ou bien doit-t-on mettre quelque chose de spécifique en place ?
5. Comment mettre en place le failover lorsqu’on a plusieurs slaves ? (on sait à peu près comment faire avec 1 slave, mais pas avec plusieurs slaves).
6. Dans la documentation il est dit : « In standby mode, the server continuously applies WAL received from the master server. The standby server can read WAL from a WAL archive (see restore_command) or directly from the master over a TCP connection (streaming replication). »
Je sais que pour le mode Streaming Replication la réplication sur le Slave est plus ou moins « immédiate ». Dans le cas où on n’utilise pas le Streaming Replication, quel paramètre du Slave indique la périodicité pour intégrer les WALs du Master dans le Slave ?
7. Vocabulaire : Quelle est la différence entre un WAL, un « journal de transaction » et un « fichier de log » ?
N'hésitez pas à me dire s'il y a des questions que vous ne comprenez pas.
Je vous remercie par avance, cordialement,
Bonjour,
Dans le cadre d'un projet d'étude, moi et mes camarades devons mettre en place un cluster de bases PostgreSQL et assurer la réplication.
Voici notre architecture :
* 3 machine contenant chacun un projet web en Java et utilisant JDBC (ou un JDBC ré-écrit par nos soins) pour assurer la communication avec une machine du Cluster PostgreSQL.
* 3 machines avec uniquement PostgreSQL installé dans chacun.
Nous n'avons bien sur pas le droit d'utiliser des librairies existantes comme HA-JDBC.
Nous avons bien sur lu la documentation :
https://wiki.postgresql.org/wiki/Replic … on_Pooling
http://docs.postgresqlfr.org/9.3/high-availability.html
... mais nous souhaiterions tout de même nous assurer d'être sûr le bon chemin et ne pas perdre de temps en revenant en arrière.
Voici donc notre série de questions :
1. En partant du principe que notre machine Master peut mourir à tout moment, quelle moyen de réplication nous conseillez-vous d'utiliser pour assurer la réplication ? Est-ce qu'une réplication en mode Master-Master devient obligatoire pour notre cas ?
2. Est-ce que PostgreSQL gère de base la réplication via des fichiers de configurations, ou faut-t-il obligatoirement effectuer une installation supplémentaire pour obtenir "pgPool-II", "Bucardo" etc. ? En effet dans la documentation on parle de serveur StandBy ( http://docs.postgresqlfr.org/9.3/warm-standby.html ) mais est-ce suffisant ? Que nous conseillez-vous de configurer ou installer ?
3. D'après ce lien : http://www.postgresql.org/message-id/51 … ujitsu.com , il est possible d'assurer le fail-over en indiquant plusieurs urls dans JDBC comme ceci :
String connectionString = "jdbc:postgresql://pgsqldc1:5432,pgsqldc2:5432/test";
3.a. Est-ce que cette solution est envisageable pour notre cas sachant qu'on active la réplication ?
3.b. Est-ce que cette solution est envisageable pour notre cas sachant qu'on souhaite utiliser un pool de connexion Java (type C3P0, BoneCP, HikariCP) avec un DataSource au lieu du DriverManager ?
4. Si au cours de notre étude nous ne pouvons pas utiliser le mode Master-Master pour une quelconque raison, comment faire pour savoir si une instance du Cluster est Master ou Slave ? Est-ce que l'appel de la fonction pg_is_in_recovery() au niveau de notre programme Java est concevable ? Ou bien existe-t-il une meilleure solution ?
Je vous remercie par avance pour votre aide, cordialement,
Bonjour,
Le disque sur lequel j'ai installé PostgreSQL est presque complet, je dois donc changer l'emplacement du dossier contenant les données sur un autre disque de la machine.
En gros les données sont présents sur l'emplacement suivant : C:\Program Files\PostgreSQL\9.2\data
Et je souhaiterais les déplacer vers : E:\postgresql\data
En allant dans le répertoire /data pour voir où les données étaient stockées j'ai remarqué que les données semblent être dans le dossier /base.
1. Existe-t-il un moyen conventionnel et simple de juste déplacer le dossier /base... ou faut-til déplacer tout le dossier /data ?
2. Faut-t-il toucher aux registres Windows pour modifier l'emplacement du répertoire contenant les données ? Comment faire lorsqu'on est sous Windows pour déplacer ses fichiers de données ?
PS:
J'ai bien sûr effectué des recherches dans la documentation avant de poster ce sujet :
http://www.postgresql.org/docs/9.2/stat … tions.html
http://docs.postgresqlfr.org/9.2/runtim … tions.html
=> Je crois comprendre qu'il faut modifier le paramètre data_directory du fichier postgresql.conf
Ainsi que sur les forums (qui m'a l'air bien expliqué ici, mais c'est pour PostgreSQL 8.1 et aucune modification n'est effectuée au niveau du postgresql.conf) :
http://www.developpez.net/forums/d22495 … ment-data/
=> J'ai peur de mal faire la chose ou faire "trop compliqué", s'il existe un moyen plus simple je suis preneur.
Infos:
OS : Windows Server
Version de PostgreSQL : 9.2
Je vous remercie par avance, cordialement,
Bonjour,
D'après la news de la beta 3 ( http://www.postgresql.org/about/news/1547/ ), il y a eu pas mal de modifications effectuées et j'ai l'impression qu'il y aura encore plusieurs beta avant la version finale de PostgreSQL 9.4.
1. Savez-vous combien de beta sont encore prévues avant la sortie de la version finale ? Est-ce qu'une date de sortie officielle existe ?
2. Est-t-il possible de mesurer l'évolution de la performance & stabilité entre les versions 9.2, 9.3 et 9.4 ? (améliorations, régressions)
Je ne dispose malheureusement que d'une simple machine (serveur). Je compte donc effectuer un dump de la base, désinstaller PostgreSQL 9.2, puis installer PostgreSQL 9.3 (ou PostgreSQL 9.4 si celui-ci sort à temps), et recharger le dump.
3. Y a-t-il un risque pour que le dump soit incompatible entre les différentes versions de PostgreSQL ? Pensez-vous qu'il existe un meilleur moyen de migration que le dump pour mon cas ?
Cordialement,
J'allais justement dire que j'avais doublement bourdé. La honte. Merci pour votre aide.
Sujet résolu.
Bonjour,
J'utilise PostgreSQL 9.2 et constate un décalage du jour de la semaine EXTRACT(DOW) et de la semaine de l'année EXTRACT(WEEK).
Exemple :
SELECT EXTRACT(DOW FROM '2014-06-01'::date) me retourne 0 pour Lundi, or le 01/06/2014 nous sommes un Dimanche.
SELECT EXTRACT(WEEK FROM '2014-06-01'::date) me retourne 22, or nous sommes en semaine 23.
L'instruction "SHOW TIMEZONE" dans PostgreSQL affiche "Europe/Brussels", mon serveur est physiquement situé en France, le "Regional Settings" de mon OS Windows Server est "français".
Comment résoudre ce problème, quel fichier paramétrer ?
Cordialement,
Bonjour,
Normalement on a le droit d'utiliser les alias dans ORDER BY. Je souhaiterais donc comprendre comment on gère un ORDER BY dans le cas où l'alias représente un case when.
Pour le moment, le seul moyen que j'ai trouvé de rendre l'exemple ci-dessus opérationnel, c'est de passer par une sous-requête :
SELECT * FROM (
SELECT
case when champ1 in ('toto', 'titi', 'tutu') then champ1 else 'tata' end as alias1,
champ2,
-- Champs agrégats (SUM, COUNT etc)
FROM tables
GROUP BY
case when champ1 in ('toto', 'titi', 'tutu') then champ1 else 'tata' end,
champ2
) T
ORDER BY case alias1 when 'tutu' then 1 when 'titi' then 2 when 'tutu' then 3 else 4 end, champ2
Bizarre
Salut,
Si j'enlève la ligne ORDER BY, la requête est opérationnelle. Donc je peux faire un "GROUP BY case when", d'ailleurs si je fais un "GROUP BY case when" c'est parce que je ne peux pas faire de "GROUP BY alias1" : en effet les alias ne sont pas autorisés dans le GROUP BY.
Concernant le ORDER BY, bien sur qu'il sur qu'il est possible de mettre des conditions.
Le problème : Impossible de combiner "GROUP BY case when" et "ORDER BY case when".
Cordialement,
Bonjour,
J'ai remarqué qu'il n'était pas possible de faire un "ORDER BY CASE WHEN mon_champ" lorsque "mon_champ" est le résultat d'un CASE WHEN.
Exemple :
SELECT
case when champ1 in ('toto', 'titi', 'tutu') then champ1 else 'tata' end as alias1,
champ2,
-- Champs agrégats (SUM, COUNT etc)
FROM tables
GROUP BY
case when champ1 in ('toto', 'titi', 'tutu') then champ1 else 'tata' end,
champ2
ORDER BY case alias1 when 'tutu' then 1 when 'titi' then 2 when 'tutu' then 3 else 4 end, champ2
Est-ce que c'est normal ?
Cordialement,
Bonjour,
pgAdmin n'est pas PostgreSQL, mais comme pgAdmin est fournit de base avec Postgresql (d'ailleurs je me vois mal utiliser PostgreSQL sans pgAdmin, avec psql uniquement par exemple), les modules fournit avec PostgreSQL doivent être stables.
J'ai remarqué ces derniers jours, avec la découverte de la faille Heartbleed/OpenSSL, que les bugs/failles ne pouvaient que nuire à la réputation des projets open source. Bien sur qu'il existe des failles/bugs dans les projets clos, mais j'ai l'impression que cela s'ébruite moins. Les développeurs des projets open source doivent doubler de vigilance, sous peine d'être pointé du doigt.
Cordialement,