Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#1 Re : Général » Comparaison serveur physique / serveur virtuel » 17/03/2020 19:09:15
Oui, la machine physique a des disques locaux et la machine virtuelle des disques sur un SAN.
Pour l'overcommit, voici les paramètres appliqués :
vm.swappiness = 1
vm.overcommit_memory = 2
vm.overcommit_ratio = 99
#2 Général » Comparaison serveur physique / serveur virtuel » 17/03/2020 18:16:41
- ced
- Réponses : 3
Bonjour,
Je mène actuellement une série de tests visant à comparer le plus objectivement possible les différences de performances de PostgreSQL entre un serveur physique et un serveur virtuel dimensionné de manière identique (même nombre de CPU , même quantité de RAM). L'objectif est d'évaluer s'il y a des écarts forts entre les deux types de serveurs (comme ce que certains utilisateurs le pressentent) ou pas.
J'ai installé PostgreSQL v11 sur les deux machines et je les ai paramétrées de la même façon (paramètres identiques du fichier postgresql.conf).
J'ai ensuite fait tourner plusieurs benchmarks avec pgbench, ou plus précisément avec pgbench-tools.
J'ai commencé par une série de tests avec des facteurs d'échelle de 1, 10, 100 et 1000 (la base est celle initialisée par défaut dans pgbench). En termes de résultats (TPS et latence), je n'observe aucune différence entre les deux serveurs. Le serveur virtuel serait même un peu plus performant...
J'ai ensuite relancé les tests avec les facteurs 100, 1000 et 10000, histoire de travailler avec une taille de base de données qui ne tienne pas en mémoire (32 GB). Là encore, les résultats des tests (TPS et latence) sont très proches, toutefois le serveur virtuel a mis 2h de plus que le serveur physique pour boucler les tests... Et quand j'analyse les logs avec PgBadger, je vois que les requêtes de type COPY et VACUUM sont plus lentes sur le serveur virtuel.
Mon interprétation est que ce qui ralentit le serveur virtuel, ce sont les écritures de données sur disque. En effet, quand je teste les temps d'écriture / lecture avec l'outil dd, les résultats sont meilleurs sur le serveur physique (180 MB/s vs 120 MB/s). Est-ce que ça vous semble être la bonne analyse ?
Je pense que pgbench ne fait qu'évaluer des performances en mémoire pure (vue que toutes les opérations sont effectuées en mémoire), sans prendre en compte des opérations d'écriture sur les disques (comme les COPY et les VACUUM). C'est bien ça ?
Merci d'avance pour votre aide dans ma compréhension des résultats.
Cédric
#3 Re : Général » comment paralléliser la commande pg_dump ? » 26/06/2019 15:39:41
Le nombre de CPU (ou "processeurs"), ce qui peut être différent du nombre de cœurs.
Pour connaître ce nombre sur une machine Linux :
cat /proc/cpuinfo | grep processor | wc -l#4 Re : Général » Arrêter le service postgresql.service pour de bon » 26/06/2019 15:37:31
Je m'auto-réponds partiellement...
A priori, c'est parce qu'il y a des services dépendants des services postgresql.
Donc, en arrêtant chaque service, puis en les masquant, j'arrive à les arrêter sans qu'ils puissent repartir tout seul :
sudo systemctl stop postgresql@10-main.service
sudo systemctl stop postgresql@11-main.service
sudo systemctl mask postgresql@10-main.service
sudo systemctl mask postgresql@11-main.serviceEt pour les redémarrer, il faut les démasquer :
sudo systemctl unmask postgresql@10-main.service
sudo systemctl unmask postgresql@11-main.service
sudo systemctl start postgresql@10-main.service
sudo systemctl start postgresql@11-main.serviceMais je ne sais pas si ce que je fais là (qui fournit le résultat attendu) est bien ou pas, et s'il y a une autre façon plus propre de faire ?
Je suis preneur de tout conseil.
Merci d'avance.
#5 Re : Général » Arrêter le service postgresql.service pour de bon » 26/06/2019 14:43:41
Petit complément : j'observe le même redémarrage automatique quand j'exécute un pg_ctlcluster ... stop depuis l'utilisateur postgres.
#6 Général » Arrêter le service postgresql.service pour de bon » 26/06/2019 14:35:52
- ced
- Réponses : 7
Bonjour,
Pour faire une montée de version majeure de PostgreSQL sous Debian Stretch, en utilisant pg_upgrade, j'ai besoin d'arrêter les deux instances (une en v10 et une en v11) sur le serveur.
Pour ça, j'utilise la commande :
sudo systemctl stop postgresql.serviceÇa fonctionne : les deux instances s'arrêtent bien.
Mais curieusement, les services se relancent tous seuls au bout d'une ou deux minutes.
Je ne suis pas spécialiste de systemctl (j'ai essayé avec la commande disable, mais ça ne change rien), mais je me doute qu'il doit y avoir une configuration quelque part pour empêcher ce relancement automatique, bien ennuyeux pour poursuivre les opérations de migration.
Comment faire pour empêcher ce redémarrage automatique du service ?
Merci d'avance pour votre aide,
Cédric
#7 Re : Optimisation » Performances et plans de requêtes spatiales » 11/09/2018 08:48:49
OK. Merci pour ton aide.
#8 Re : Optimisation » Performances et plans de requêtes spatiales » 10/09/2018 13:24:25
Bonjour Guillaume,
Merci pour ta réponse.
Est-ce que ça peut être la CTE et la fonction ST_Transform qui entraînent un si petit nombre de blocs lus dans la deuxième requête par rapport à la troisième ?
#9 Optimisation » Performances et plans de requêtes spatiales » 05/09/2018 09:58:05
- ced
- Réponses : 4
Bonjour,
Je dispose de deux tables contenant des géométries :
* table inv_exp_nm.e1point : contient des points, la géométrie a pour SRID un code de référence spatial "utilisateur" (c'est du Lambert 93 tenant compte de la grille de reprojection lors du changement de référentiel spatial entre Lambert 2 étendu et Lambert 93). Il s'agit donc du SRID 910001 dans ma table spatial_ref_sys ;
* table contours.contour_utilisateur_geom : contient des polygones, la géométrie a pour SRID le code EPSG du Lambert 93 (qui ne tient pas compte de la grille de repojection). C'est le SRID 2154.
Les géométries des deux tables ont des index spatiaux.
Lorsqu'on croise un polygone issu de la table des contours avec la table des points, la solution qui vient de suite consiste à faire une jointure spatiale entre points et polygones avec ST_INTERSECTS, en reprojetant à la volée le polygone en Lambert 93 "maison" (code SRID 910001).
Voici la requête :
SELECT npp
FROM inv_exp_nm.e1point e1
JOIN contours.contour_utilisateur_geom c ON ST_Intersects(ST_Transform(e1.geom, 2154), c.the_geom)
WHERE id_contour = '299';Elle met 5 minutes à s'exécuter... Voici son plan d'exécution:
Nested Loop (cost=5.08..363.93 rows=285 width=17) (actual time=457.446..309617.455 rows=12824 loops=1)
Buffers: shared hit=221431
-> Index Scan using pk_contour_utilisateur_geom on contour_utilisateur_geom c (cost=0.14..8.16 rows=1 width=70362) (actual time=0.021..0.029 rows=1 loops=1)
Index Cond: ((id_contour)::text = '299'::text)
Buffers: shared hit=2
-> Bitmap Heap Scan on e1point e1 (cost=4.94..355.48 rows=29 width=49) (actual time=457.420..309610.839 rows=12824 loops=1)
Recheck Cond: (geom && st_transform(c.the_geom, 910001))
Filter: _st_intersects(geom, st_transform(c.the_geom, 910001))
Rows Removed by Filter: 8892
Heap Blocks: exact=4074
Buffers: shared hit=221429
-> Bitmap Index Scan on idx_e1point_geom (cost=0.00..4.93 rows=86 width=0) (actual time=2.678..2.678 rows=21716 loops=1)
Index Cond: (geom && st_transform(c.the_geom, 910001))
Buffers: shared hit=173
Planning time: 0.205 ms
Execution time: 309621.410 ms
Si on réécrit la requête en isolant la reprojection du polygone dans une CTE, le temps d'exécution (pour un résultat identique) descend à 250 ms !
Voici la nouvelle requête :
EXPLAIN (ANALYZE, buffers, timing)
WITH contour AS (SELECT ST_Transform(the_geom, 910001) as geom
FROM contours.contour_utilisateur_geom
WHERE id_contour = '299'
)
SELECT npp
FROM inv_exp_nm.e1point e1
INNER JOIN contour ON (ST_Intersects(contour.geom, e1.geom));Et son plan d'exécution :
Nested Loop (cost=13.10..363.52 rows=285 width=17) (actual time=19.643..252.563 rows=12824 loops=1)
Buffers: shared hit=4265
CTE contour
-> Index Scan using pk_contour_utilisateur_geom on contour_utilisateur_geom (cost=0.14..8.16 rows=1 width=32) (actual time=14.454..14.456 rows=1 loops=1)
Index Cond: ((id_contour)::text = '299'::text)
Buffers: shared hit=18
-> CTE Scan on contour (cost=0.00..0.02 rows=1 width=32) (actual time=14.508..14.511 rows=1 loops=1)
Buffers: shared hit=18
-> Bitmap Heap Scan on e1point e1 (cost=4.94..355.04 rows=29 width=49) (actual time=5.130..235.789 rows=12824 loops=1)
Recheck Cond: (contour.geom && geom)
Filter: _st_intersects(contour.geom, geom)
Rows Removed by Filter: 8892
Heap Blocks: exact=4074
Buffers: shared hit=4247
-> Bitmap Index Scan on idx_e1point_geom (cost=0.00..4.93 rows=86 width=0) (actual time=2.683..2.683 rows=21716 loops=1)
Index Cond: (contour.geom && geom)
Buffers: shared hit=173
Planning time: 0.311 ms
Execution time: 253.495 ms
Quand je regarde les plans d'exécution, j'interprète la source du problème dans la première requête sur le filtre qui réaliser la reprojection à chaque bitmap heap scan sur la table des points (c'est là que le temps explose). Je me trompe ?
Du coup, comme les deux projections sont du Lambert 93 (et qu'il n'y a pas, dans cette requête du moins, d'autre couche spatiale en jeu avec du Lambert 2 étendu), j'ai mis à jour le SRID de la couche des contours (les polygones) en Lambert 93 "utilisateur" (le code SRID 910001) comme ça :
SELECT updategeometrysrid('contours', 'contour_utilisateur_geom', 'the_geom', 910001);La première requête spatiale devient alors :
SELECT npp
FROM inv_exp_nm.e1point e1
JOIN contours.contour_utilisateur_geom c ON ST_Intersects(e1.geom, c.the_geom)
WHERE id_contour = '299';Elle met 11 secondes à s'exécuter.
Voici le plan d'exécution :
Nested Loop (cost=5.08..363.49 rows=18830 width=17) (actual time=15.856..7647.523 rows=12824 loops=1)
Buffers: shared hit=221419
-> Index Scan using pk_contour_utilisateur_geom on contour_utilisateur_geom c (cost=0.14..8.16 rows=1 width=70362) (actual time=0.013..0.014 rows=1 loops=1)
Index Cond: ((id_contour)::text = '299'::text)
Buffers: shared hit=2
-> Bitmap Heap Scan on e1point e1 (cost=4.94..355.04 rows=29 width=49) (actual time=15.840..7643.820 rows=12824 loops=1)
Recheck Cond: (geom && c.the_geom)
Filter: _st_intersects(geom, c.the_geom)
Rows Removed by Filter: 8892
Heap Blocks: exact=4074
Buffers: shared hit=221417
-> Bitmap Index Scan on idx_e1point_geom (cost=0.00..4.93 rows=86 width=0) (actual time=2.637..2.637 rows=21716 loops=1)
Index Cond: (geom && c.the_geom)
Buffers: shared hit=173
Planning time: 0.530 ms
Execution time: 7649.239 ms
Là encore, le nœud critique semble être le Bitmap Heap Scan sur la table des points. La différence avec le plan d'exécution de la deuxième requête semble être la taille des buffers lus en mémoire, qui est plus élevée. Est-ce que c'est ça qui augmente le temps d'exécution ? Si oui, pourquoi cette taille est supérieure avec cette dernière requête ?
Merci d'avance pour votre aide,
Cédric
#10 Re : Optimisation » Estimation des lignes issues d'une jointure » 27/06/2018 15:27:19
Effectivement, mais dans le cas présent, compte tenu de l'erreur sur le nombre réel de lignes, il se trouve qu'il devient la mauvaise option.
C'est pour ça qu'il faut que je cherche à améliorer l'estimation du nombre de lignes. C'est plus là qu'est le point sensible.
Encore merci pour tes réponses.
#11 Re : Optimisation » Estimation des lignes issues d'une jointure » 27/06/2018 11:08:30
Merci Guillaume pour cette piste de types différents. Je vais essayer de creuser de ce côté-là.
Dans la requête que j'ai indiquée, le planificateur ne choisit effectivement pas le NestedLoop, mais avec plus de jointures, là il finit par choisir cette option, ce qui cause des problèmes de performances.
Je vais essayer de réécrire les requêtes qui font les jointures entre données en base et métadonnées pour lever le problème.
#12 Optimisation » Estimation des lignes issues d'une jointure » 21/06/2018 10:16:52
- ced
- Réponses : 4
Bonjour,
J'ai la requête suivante :
SELECT p2.npp, round(p2.xgps :: numeric, 8) as xgps, round(p2.ygps :: numeric, 8) as ygps, echelon_init as echelon
FROM inv_prod.e2point p2
INNER JOIN metaifn.abmode m2 ON m2.mode = echelon_init and m2.unite = 'EX'
INNER JOIN inv_prod.unite_ech ue ON p2.id_unite = ue.id_unite
INNER JOIN inv_prod.echantillon e ON ue.id_ech = e.id_ech
WHERE e.incref = 11
AND p2.tir2 = '1'
AND e.inv IN ('R', 'T');Dont la sortie d'EXPLAIN (ANALYZE) donne ceci :
Hash Join (cost=22902.45..31314.85 rows=16 width=84) (actual time=126.721..159.288 rows=7518 loops=1)
Output: p2.npp, round((p2.xgps)::numeric, 8), round((p2.ygps)::numeric, 8), p2.echelon_init
Hash Cond: (p2.echelon_init = (m2.mode)::bpchar)
Buffers: shared hit=4861
-> Hash Join (cost=14920.32..23079.09 rows=16887 width=36) (actual time=126.122..140.296 rows=7518 loops=1)
Output: p2.npp, p2.xgps, p2.ygps, p2.echelon_init
Hash Cond: (ue.id_unite = p2.id_unite)
Buffers: shared hit=4861
-> Nested Loop (cost=0.43..7442.72 rows=146030 width=4) (actual time=0.035..30.451 rows=100184 loops=1)
Output: ue.id_unite
Buffers: shared hit=617
-> Seq Scan on inv_prod.echantillon e (cost=0.00..1.58 rows=3 width=4) (actual time=0.018..0.035 rows=4 loops=1)
Output: e.id_ech, e.nom_ech, e.type_enquete, e.type_unites, e.usite, e.site, e.surf_dom, e.deb_temp, e.fin_temp, e.proprietaire, e.phase_stat, e.id_parent, e.taille_ech, e.url_script, e.cyc, e.incref, e.inv
Filter: ((e.inv = ANY ('{R,T}'::bpchar[])) AND (e.incref = 11))
Rows Removed by Filter: 35
Buffers: shared hit=1
-> Index Only Scan using unite_ech_pkey on inv_prod.unite_ech ue (cost=0.43..1993.61 rows=48677 width=8) (actual time=0.011..4.669 rows=25046 loops=4)
Output: ue.id_ech, ue.famille, ue.format, ue.id_unite
Index Cond: (ue.id_ech = e.id_ech)
Heap Fetches: 0
Buffers: shared hit=616
-> Hash (cost=13360.55..13360.55 rows=124747 width=40) (actual time=90.332..90.332 rows=124537 loops=1)
Output: p2.npp, p2.xgps, p2.ygps, p2.echelon_init, p2.id_unite
Buckets: 131072 Batches: 1 Memory Usage: 10506kB
Buffers: shared hit=4244
-> Bitmap Heap Scan on inv_prod.e2point p2 (cost=2375.21..13360.55 rows=124747 width=40) (actual time=10.731..63.092 rows=124537 loops=1)
Output: p2.npp, p2.xgps, p2.ygps, p2.echelon_init, p2.id_unite
Recheck Cond: (p2.tir2 = '1'::bpchar)
Heap Blocks: exact=3882
Buffers: shared hit=4244
-> Bitmap Index Scan on idx_e2point_tir2 (cost=0.00..2344.03 rows=124747 width=0) (actual time=10.145..10.145 rows=124537 loops=1)
Index Cond: (p2.tir2 = '1'::bpchar)
Buffers: shared hit=362
-> Hash (cost=7982.01..7982.01 rows=10 width=5) (actual time=0.571..0.571 rows=50 loops=1)
Output: m2.mode
Buckets: 1024 Batches: 1 Memory Usage: 10kB
-> Foreign Scan on metaifn.abmode m2 (cost=100.00..7982.01 rows=10 width=5) (actual time=0.553..0.558 rows=50 loops=1)
Output: m2.mode
Remote SQL: SELECT mode FROM metaifn.abmode WHERE ((unite = 'EX'::text))
Planning time: 0.687 ms
Execution time: 160.383 ms
Ce que je ne comprends pas bien, c'est comment le planificateur, sur la dernière jointure, en arrive à estimer qu'il n'y aura que 16 lignes à l'arrivée (alors qu'en réalité, il y en a 7518)... Il fait l'hypothèse qu'il n'y a pas de correspondance sur toutes les lignes des deux tables ?
Merci d'avance pour vos éclaircissements.
#13 Re : Installation » Instal Postgresql 9.3.2 /Windows server 2016/VMWare erreur cluster » 19/06/2018 15:29:46
Bonjour,
Y a-t-il un antivirus d'activé ?
La plupart des fois où j'ai rencontré ce problème, c'était à cause de l'antivirus, qu'il fallait désactiver le temps de l'installation.
#14 Re : Général » Requete pivot » 26/03/2018 08:07:50
Bonjour,
Vous pouvez passer par l'extension tablefunc : https://www.postgresql.org/docs/current … efunc.html
Ou bien en utilisant la fonction décrite sur le wiki de PostgreSQL : https://wiki.postgresql.org/wiki/Pivot_query (jamais testé pour ma part).
#15 Re : Optimisation » Optimisation d'une requête sans désactiver nested loop » 20/02/2018 12:09:22
En attendant le passage à la v10, j'ai contourné le problème en créant la vue à partir d'une fonction SQL qui exécute la requête et désactive le nested loop localement à la fonction (surcharge de enable_nestloop).
Ça fonctionne très bien : le temps d'exécution de la requête sur la vue redescend à 3 secondes, ce qui est parfaitement acceptable. Et aucun impact sur le serveur puisque je ne modifie aucun paramètre global.
#16 Re : Optimisation » Optimisation d'une requête sans désactiver nested loop » 20/02/2018 11:36:37
J'ai creusé ce problème d'estimation du nombre de lignes. C'est un problème de sélectivité de l'optimiseur qui se résout très bien avec les statistiques multi-colonnes de la v10. En créant une statistique sur les colonnes GUNITE, UNITE, la sélectivité de la requête en question remonte à 19 et le nested loop n'est plus choisi par défaut par l'optimiseur.
Ça me fait une bonne raison supplémentaire pour argumenter une montée de version.
Encore merci pour l'aide apportée.
#17 Re : Optimisation » Optimisation d'une requête sans désactiver nested loop » 19/02/2018 13:44:26
Merci pour l'explication.
Effectivement, les stats sont bien identiques. Je vais rester sur la CTE faute de mieux.
Bonne journée,
Cédric
#18 Re : Optimisation » Optimisation d'une requête sans désactiver nested loop » 19/02/2018 11:39:02
Bonjour Guillaume,
Merci de bien vouloir m'aider et pardon pour la mauvaise mise en forme.
J'ai réédité mon premier message pour mettre la sortie d'un EXPLAIN avec les coûts.
J'en ai profité pour indiquer la ligne sur laquelle, je pense, une mauvaise estimation de nombre de ligne est faite, ce qui explique pourquoi le nested loop est privilégié à tort.
Comme ce sont des tables étrangères, le problème peut-il venir de là ? J'ai pourtant fait un ANALYZE de ces tables. Mais apparemment, les statistiques ne sont pas tout à fait justes, puisque le nombre de lignes est sous-estimé (1 vs 19 en réalité). Ça expliquerait aussi pourquoi la requête avec la CTE est plus efficace : le nombre de lignes estimées à l'issue de la CTE pour la même jointure est correct (19 lignes) et c'est alors un hash join qui est fait, plus efficace dans le cas présent.
Comment est-ce que je peux faire pour améliorer ces stats sur la table étrangère (si toutefois le problème vient bien de là) ?
Encore merci pour l'aide apportée.
Cédric
#19 Re : Optimisation » Optimisation d'une requête sans désactiver nested loop » 16/02/2018 19:26:24
J'arrive à contourner le problème en réécrivant la requête comme ça :
WITH meta AS (
SELECT unite, mode, libelle
FROM metaifn.abmode
WHERE unite IN ('PRO_2015', 'PF', 'SER_86', 'TOPO', 'HUMUS', 'HUMUSD1', 'ROCHE')
)
SELECT f.npp, p1.nph
, f.numboite
, CASE WHEN p1.incref < 10 THEN 2010 + p1.incref ELSE 2005 + p1.incref END AS campagne
, p1.dep
, ep2.pro_nm, mpro.libelle AS lib_pro_nm
, p1.pro, mpr.libelle AS lib_pro
, p1.zp
, p1.ser_86, mser.libelle AS lib_ser_86
, LEFT(p1.ser_86, 1) AS greco
, ec.pent2
, ec.topo, mtop.libelle AS lib_topo
, ec.humus, mhum.libelle AS lib_humus
-- , humg1.mode AS humusg1, humg1.libelle AS lib_humusg1
, ec.affroc
, ec.roche, mroc.libelle AS lib_roche
, eec.rayo
, eec.reserutile
-- ,
FROM inv_prod.e1point p1
INNER JOIN inv_prod.g3foret f ON p1.npp = f.npp
INNER JOIN inv_prod.e2point p2 ON p1.npp = p2.npp
LEFT JOIN inv_exp_nm.e2point ep2 ON p1.npp = ep2.npp
INNER JOIN inv_prod.g3ecologie ec ON p1.npp = ec.npp
LEFT JOIN inv_exp_nm.g3ecologie eec ON p1.npp = eec.npp
LEFT JOIN meta mpro ON mpro.unite = 'PRO_2015' AND ep2.pro_nm = mpro.mode
LEFT JOIN meta mpr ON mpr.unite = 'PF' AND p1.pro = mpr.mode
INNER JOIN meta mser ON mser.unite = 'SER_86' AND p1.ser_86 = mser.mode
INNER JOIN meta mtop ON mtop.unite = 'TOPO' AND ec.topo = mtop.mode
INNER JOIN meta mhum ON mhum.unite = 'HUMUS' AND ec.humus = mhum.mode
INNER JOIN metaifn.abgroupe ghum ON ghum.unite = mhum.unite AND ghum.gunite = 'HUMUSD1' AND ghum.mode = mhum.mode
--INNER JOIN metaifn.abmode humg1 ON ghum.gunite = humg1.unite AND humg1.mode = ghum.gmode
LEFT JOIN meta mroc ON mroc.unite = 'ROCHE' AND ec.roche = mroc.mode
WHERE f.numboite IS NOT NULL
ORDER BY campagne, npp;Le plan d'exécution associé devient alors le suivant :
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=117298.61..117298.62 rows=1 width=930) (actual time=2990.373..2990.829 rows=5431 loops=1)
Sort Key: (CASE WHEN (p1.incref < 10) THEN (2010 + p1.incref) ELSE (2005 + p1.incref) END), f.npp
Sort Method: quicksort Memory: 1676kB
CTE meta
-> Foreign Scan on abmode (cost=100.00..9778.22 rows=218 width=30) (actual time=20.849..21.951 rows=300 loops=1)
-> Hash Left Join (cost=73385.98..107520.39 rows=1 width=930) (actual time=1394.691..2962.191 rows=5431 loops=1)
Hash Cond: (ec.roche = (mroc.mode)::bpchar)
-> Hash Join (cost=73381.06..107515.44 rows=1 width=758) (actual time=1394.569..2957.905 rows=5431 loops=1)
Hash Cond: (ec.topo = (mtop.mode)::bpchar)
-> Hash Join (cost=73376.15..107510.51 rows=1 width=620) (actual time=1372.489..2934.007 rows=5431 loops=1)
Hash Cond: (p1.ser_86 = (mser.mode)::bpchar)
-> Hash Join (cost=73371.23..107505.58 rows=1 width=482) (actual time=1372.407..2931.824 rows=5431 loops=1)
Hash Cond: (ec.humus = (mhum.mode)::bpchar)
-> Hash Left Join (cost=60949.31..95063.03 rows=5431 width=344) (actual time=1371.819..2929.411 rows=5431 loops=1)
Hash Cond: (p1.pro = (mpr.mode)::bpchar)
-> Hash Left Join (cost=60944.40..95037.52 rows=5431 width=206) (actual time=1371.770..2928.333 rows=5431 loops=1)
Hash Cond: (ep2.pro_nm = (mpro.mode)::bpchar)
-> Hash Right Join (cost=60939.48..95011.96 rows=5431 width=68) (actual time=1371.694..2926.142 rows=5431 loops=1)
Hash Cond: (ep2.npp = p1.npp)
-> Foreign Scan on e2point ep2 (cost=100.00..31860.92 rows=608964 width=20) (actual time=0.835..1966.443 rows=608964 loops=1)
-> Hash (cost=60771.59..60771.59 rows=5431 width=82) (actual time=864.189..864.189 rows=5431 loops=1)
Buckets: 8192 Batches: 1 Memory Usage: 740kB
-> Hash Join (cost=42823.62..60771.59 rows=5431 width=82) (actual time=697.044..861.788 rows=5431 loops=1)
Hash Cond: (p2.npp = p1.npp)
-> Seq Scan on e2point p2 (cost=0.00..15382.51 rows=675851 width=17) (actual time=0.043..73.762 rows=675851 loops=1)
-> Hash (cost=42755.73..42755.73 rows=5431 width=99) (actual time=694.655..694.655 rows=5431 loops=1)
Buckets: 8192 Batches: 1 Memory Usage: 825kB
-> Hash Right Join (cost=38236.08..42755.73 rows=5431 width=99) (actual time=300.793..691.962 rows=5431 loops=1)
Hash Cond: (eec.npp = p1.npp)
-> Foreign Scan on g3ecologie eec (cost=100.00..4324.86 rows=77662 width=27) (actual time=2.411..378.582 rows=77662 loops=1)
-> Hash (cost=38068.19..38068.19 rows=5431 width=89) (actual time=298.327..298.327 rows=5431 loops=1)
Buckets: 8192 Batches: 1 Memory Usage: 742kB
-> Gather (cost=5376.97..38068.19 rows=5431 width=89) (actual time=81.160..295.911 rows=5431 loops=1)
Workers Planned: 4
Workers Launched: 4
-> Hash Join (cost=4376.97..36525.09 rows=1358 width=89) (actual time=112.967..263.113 rows=1086 loops=5)
Hash Cond: (p1.npp = f.npp)
-> Parallel Seq Scan on e1point p1 (cost=0.00..31025.21 rows=295821 width=40) (actual time=1.780..105.096 rows=236657 loops=5)
-> Hash (cost=4309.09..4309.09 rows=5431 width=49) (actual time=84.918..84.918 rows=5431 loops=5)
Buckets: 8192 Batches: 1 Memory Usage: 499kB
-> Hash Join (cost=1907.79..4309.09 rows=5431 width=49) (actual time=63.472..77.886 rows=5431 loops=5)
Hash Cond: (ec.npp = f.npp)
-> Seq Scan on g3ecologie ec (cost=0.00..2057.90 rows=77090 width=30) (actual time=1.060..14.484 rows=77090 loops=5)
-> Hash (cost=1839.90..1839.90 rows=5431 width=19) (actual time=29.048..29.048 rows=5431 loops=5)
Buckets: 8192 Batches: 1 Memory Usage: 340kB
-> Seq Scan on g3foret f (cost=0.00..1839.90 rows=5431 width=19) (actual time=1.681..27.894 rows=5431 loops=5)
Filter: (numboite IS NOT NULL)
Rows Removed by Filter: 71659
-> Hash (cost=4.91..4.91 rows=1 width=180) (actual time=0.049..0.049 rows=7 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> CTE Scan on meta mpro (cost=0.00..4.91 rows=1 width=180) (actual time=0.010..0.043 rows=7 loops=1)
Filter: ((unite)::text = 'PRO_2015'::text)
Rows Removed by Filter: 293
-> Hash (cost=4.91..4.91 rows=1 width=180) (actual time=0.039..0.039 rows=5 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> CTE Scan on meta mpr (cost=0.00..4.91 rows=1 width=180) (actual time=0.005..0.035 rows=5 loops=1)
Filter: ((unite)::text = 'PF'::text)
Rows Removed by Filter: 295
-> Hash (cost=12421.90..12421.90 rows=1 width=180) (actual time=0.579..0.579 rows=19 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Hash Join (cost=104.92..12421.90 rows=1 width=180) (actual time=0.564..0.572 rows=19 loops=1)
Hash Cond: ((ghum.mode)::text = (mhum.mode)::text)
-> Foreign Scan on abgroupe ghum (cost=100.00..12416.97 rows=1 width=10) (actual time=0.491..0.491 rows=19 loops=1)
-> Hash (cost=4.91..4.91 rows=1 width=222) (actual time=0.044..0.044 rows=19 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> CTE Scan on meta mhum (cost=0.00..4.91 rows=1 width=222) (actual time=0.001..0.039 rows=19 loops=1)
Filter: ((unite)::text = 'HUMUS'::text)
Rows Removed by Filter: 281
-> Hash (cost=4.91..4.91 rows=1 width=180) (actual time=0.066..0.066 rows=86 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 13kB
-> CTE Scan on meta mser (cost=0.00..4.91 rows=1 width=180) (actual time=0.024..0.044 rows=86 loops=1)
Filter: ((unite)::text = 'SER_86'::text)
Rows Removed by Filter: 214
-> Hash (cost=4.91..4.91 rows=1 width=180) (actual time=22.067..22.067 rows=10 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> CTE Scan on meta mtop (cost=0.00..4.91 rows=1 width=180) (actual time=21.894..22.061 rows=10 loops=1)
Filter: ((unite)::text = 'TOPO'::text)
Rows Removed by Filter: 290
-> Hash (cost=4.91..4.91 rows=1 width=180) (actual time=0.095..0.095 rows=166 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 17kB
-> CTE Scan on meta mroc (cost=0.00..4.91 rows=1 width=180) (actual time=0.006..0.053 rows=166 loops=1)
Filter: ((unite)::text = 'ROCHE'::text)
Rows Removed by Filter: 134
Planning time: 7.815 ms
Execution time: 2993.754 ms
(85 lignes)
Cette fois-ci, dans la CTE, le nombre de lignes pour la jointure qui coinçait auparavant est juste : 19 lignes. Et donc, pas de nested loop...
#20 Optimisation » Optimisation d'une requête sans désactiver nested loop » 16/02/2018 18:28:38
- ced
- Réponses : 8
Bonjour,
J'exécute la requête suivante :
SELECT f.npp, p1.nph
, f.numboite
, CASE WHEN p1.incref < 10 THEN 2010 + p1.incref ELSE 2005 + p1.incref END AS campagne
, p1.dep
, ep2.pro_nm, mpro.libelle AS lib_pro_nm
, p1.pro, mpr.libelle AS lib_pro
, p1.zp
, p1.ser_86, mser.libelle AS lib_ser_86
, LEFT(p1.ser_86, 1) AS greco
, ec.pent2
, ec.topo, mtop.libelle AS lib_topo
, ec.humus, mhum.libelle AS lib_humus
-- , humg1.mode AS humusg1, humg1.libelle AS lib_humusg1
, ec.affroc
, ec.roche, mroc.libelle AS lib_roche
, eec.rayo
, eec.reserutile
-- ,
FROM inv_prod.e1point p1
INNER JOIN inv_prod.g3foret f ON p1.npp = f.npp
INNER JOIN inv_prod.e2point p2 ON p1.npp = p2.npp
LEFT JOIN inv_exp_nm.e2point ep2 ON p1.npp = ep2.npp
INNER JOIN inv_prod.g3ecologie ec ON p1.npp = ec.npp
LEFT JOIN inv_exp_nm.g3ecologie eec ON p1.npp = eec.npp
LEFT JOIN metaifn.abmode mpro ON mpro.unite = 'PRO_2015' AND ep2.pro_nm = mpro.mode
LEFT JOIN metaifn.abmode mpr ON mpr.unite = 'PF' AND p1.pro = mpr.mode
INNER JOIN metaifn.abmode mser ON mser.unite = 'SER_86' AND p1.ser_86 = mser.mode
INNER JOIN metaifn.abmode mtop ON mtop.unite = 'TOPO' AND ec.topo = mtop.mode
INNER JOIN metaifn.abmode mhum ON mhum.unite = 'HUMUS' AND ec.humus = mhum.mode
INNER JOIN metaifn.abgroupe ghum ON ghum.unite = mhum.unite AND ghum.gunite = 'HUMUSD1' AND ghum.mode = mhum.mode
--INNER JOIN metaifn.abmode humg1 ON ghum.gunite = humg1.unite AND humg1.mode = ghum.gmode
LEFT JOIN metaifn.abmode mroc ON mroc.unite = 'ROCHE' AND ec.roche = mroc.mode
WHERE f.numboite IS NOT NULL
ORDER BY campagne, npp;Son exécution prend environ 40 secondes, et voici le résultat d'un EXPLAIN (ANALYZE) :
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=110397.51..110397.51 rows=1 width=216) (actual time=60972.179..60972.645 rows=5431 loops=1)
Sort Key: (CASE WHEN (p1.incref < 10) THEN (2010 + p1.incref) ELSE (2005 + p1.incref) END), f.npp
Sort Method: quicksort Memory: 1676kB
-> Nested Loop Left Join (cost=32184.76..110397.50 rows=1 width=216) (actual time=2667.623..60939.240 rows=5431 loops=1)
Join Filter: (ec.roche = (mroc.mode)::bpchar)
Rows Removed by Join Filter: 896126
-> Nested Loop (cost=32084.76..102396.01 rows=1 width=163) (actual time=2667.019..55562.972 rows=5431 loops=1)
Join Filter: (ec.topo = (mtop.mode)::bpchar)
Rows Removed by Join Filter: 48879
-> Nested Loop (cost=31984.76..94399.45 rows=1 width=144) (actual time=2666.581..55548.509 rows=5431 loops=1)
Join Filter: (p1.ser_86 = (mser.mode)::bpchar)
Rows Removed by Join Filter: 461635
-> Nested Loop (cost=31884.76..86402.89 rows=1 width=125) (actual time=2665.859..55458.842 rows=5431 loops=1)
Join Filter: ((mhum.mode)::bpchar = ec.humus)
Rows Removed by Join Filter: 97758
-> Foreign Scan (cost=100.00..20313.31 rows=1 width=24) (actual time=1.261..1.266 rows=19 loops=1)
Relations: (metaifn.abmode mhum) INNER JOIN (metaifn.abgroupe ghum)
-> Hash Left Join (cost=31784.76..66021.69 rows=5431 width=106) (actual time=742.608..2917.762 rows=5431 loops=19)
Hash Cond: (p1.pro = (mpr.mode)::bpchar)
-> Hash Left Join (cost=23788.20..57942.16 rows=5431 width=87) (actual time=742.582..2916.633 rows=5431 loops=19)
Hash Cond: (ep2.pro_nm = (mpro.mode)::bpchar)
-> Hash Right Join (cost=15791.63..49864.12 rows=5431 width=68) (actual time=742.551..2914.761 rows=5431 loops=19)
Hash Cond: (ep2.npp = p1.npp)
-> Foreign Scan on e2point ep2 (cost=100.00..31860.92 rows=608964 width=20) (actual time=0.903..2792.405 rows=608964 loops=19)
-> Hash (cost=15623.75..15623.75 rows=5431 width=82) (actual time=494.773..494.773 rows=5431 loops=1)
Buckets: 8192 Batches: 1 Memory Usage: 740kB
-> Hash Right Join (cost=11104.09..15623.75 rows=5431 width=82) (actual time=91.340..492.405 rows=5431 loops=1)
Hash Cond: (eec.npp = p1.npp)
-> Foreign Scan on g3ecologie eec (cost=100.00..4324.86 rows=77662 width=27) (actual time=2.033..388.705 rows=77662 loops=1)
-> Hash (cost=10936.21..10936.21 rows=5431 width=72) (actual time=89.255..89.255 rows=5431 loops=1)
Buckets: 8192 Batches: 1 Memory Usage: 652kB
-> Gather (cost=2908.64..10936.21 rows=5431 width=72) (actual time=26.653..87.045 rows=5431 loops=1)
Workers Planned: 1
Workers Launched: 1
-> Nested Loop (cost=1908.64..9393.11 rows=3195 width=72) (actual time=20.355..79.790 rows=2716 loops=2)
Join Filter: (f.npp = p1.npp)
-> Nested Loop (cost=1908.21..7289.70 rows=3195 width=66) (actual time=20.332..50.710 rows=2716 loops=2)
Join Filter: (f.npp = p2.npp)
-> Hash Join (cost=1907.79..3850.26 rows=3195 width=49) (actual time=20.293..23.829 rows=2716 loops=2)
Hash Cond: (ec.npp = f.npp)
-> Parallel Seq Scan on g3ecologie ec (cost=0.00..1740.47 rows=45347 width=30) (actual time=0.005..4.617 rows=38545 loops=2)
-> Hash (cost=1839.90..1839.90 rows=5431 width=19) (actual time=12.507..12.507 rows=5431 loops=2)
Buckets: 8192 Batches: 1 Memory Usage: 340kB
-> Seq Scan on g3foret f (cost=0.00..1839.90 rows=5431 width=19) (actual time=0.695..10.714 rows=5431 loops=2)
Filter: (numboite IS NOT NULL)
Rows Removed by Filter: 71659
-> Index Only Scan using pke2point on e2point p2 (cost=0.42..1.06 rows=1 width=17) (actual time=0.009..0.009 rows=1 loops=5431)
Index Cond: (npp = ec.npp)
Heap Fetches: 2680
-> Index Scan using pke1point on e1point p1 (cost=0.43..0.65 rows=1 width=40) (actual time=0.010..0.010 rows=1 loops=5431)
Index Cond: (npp = p2.npp)
-> Hash (cost=7996.44..7996.44 rows=10 width=24) (actual time=0.510..0.510 rows=7 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Foreign Scan on abmode mpro (cost=100.00..7996.44 rows=10 width=24) (actual time=0.501..0.503 rows=7 loops=1)
-> Hash (cost=7996.44..7996.44 rows=10 width=24) (actual time=0.434..0.434 rows=5 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Foreign Scan on abmode mpr (cost=100.00..7996.44 rows=10 width=24) (actual time=0.420..0.420 rows=5 loops=1)
-> Foreign Scan on abmode mser (cost=100.00..7996.44 rows=10 width=24) (actual time=0.000..0.005 rows=86 loops=5431)
-> Foreign Scan on abmode mtop (cost=100.00..7996.44 rows=10 width=24) (actual time=0.000..0.001 rows=10 loops=5431)
-> Foreign Scan on abmode mroc (cost=100.00..7999.46 rows=161 width=24) (actual time=0.447..0.778 rows=166 loops=5431)
Planning time: 14.210 ms
Execution time: 61004.853 ms
(62 lignes)
Devant la durée, j'ai désactivé les boucles (nested loop).
La requête prend alors 3 secondes pour s'exécuter et voici le plan d'exécution :
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=155498.14..155498.14 rows=1 width=216) (actual time=3089.724..3090.152 rows=5431 loops=1)
Sort Key: (CASE WHEN (p1.incref < 10) THEN (2010 + p1.incref) ELSE (2005 + p1.incref) END), f.npp
Sort Method: quicksort Memory: 1676kB
-> Hash Left Join (cost=121240.52..155498.13 rows=1 width=216) (actual time=1499.085..3061.587 rows=5431 loops=1)
Hash Cond: (ec.roche = (mroc.mode)::bpchar)
-> Hash Join (cost=113239.05..147496.43 rows=1 width=163) (actual time=1498.167..3056.377 rows=5431 loops=1)
Hash Cond: (ec.topo = (mtop.mode)::bpchar)
-> Hash Join (cost=105242.49..139499.84 rows=1 width=144) (actual time=1497.530..3053.863 rows=5431 loops=1)
Hash Cond: (p1.ser_86 = (mser.mode)::bpchar)
-> Hash Join (cost=97245.92..131503.26 rows=1 width=125) (actual time=1496.821..3051.040 rows=5431 loops=1)
Hash Cond: (ec.humus = (mhum.mode)::bpchar)
-> Hash Left Join (cost=76932.60..111169.54 rows=5431 width=106) (actual time=1495.633..3047.981 rows=5431 loops=1)
Hash Cond: (p1.pro = (mpr.mode)::bpchar)
-> Hash Left Join (cost=68936.04..103090.00 rows=5431 width=87) (actual time=1495.220..3046.425 rows=5431 loops=1)
Hash Cond: (ep2.pro_nm = (mpro.mode)::bpchar)
-> Hash Right Join (cost=60939.48..95011.96 rows=5431 width=68) (actual time=1494.643..3043.939 rows=5431 loops=1)
Hash Cond: (ep2.npp = p1.npp)
-> Foreign Scan on e2point ep2 (cost=100.00..31860.92 rows=608964 width=20) (actual time=0.808..1960.520 rows=608964 loops=1)
-> Hash (cost=60771.59..60771.59 rows=5431 width=82) (actual time=984.847..984.847 rows=5431 loops=1)
Buckets: 8192 Batches: 1 Memory Usage: 740kB
-> Hash Join (cost=42823.62..60771.59 rows=5431 width=82) (actual time=819.981..982.527 rows=5431 loops=1)
Hash Cond: (p2.npp = p1.npp)
-> Seq Scan on e2point p2 (cost=0.00..15382.51 rows=675851 width=17) (actual time=0.051..71.541 rows=675851 loops=1)
-> Hash (cost=42755.73..42755.73 rows=5431 width=99) (actual time=817.746..817.746 rows=5431 loops=1)
Buckets: 8192 Batches: 1 Memory Usage: 825kB
-> Hash Right Join (cost=38236.08..42755.73 rows=5431 width=99) (actual time=424.647..815.196 rows=5431 loops=1)
Hash Cond: (eec.npp = p1.npp)
-> Foreign Scan on g3ecologie eec (cost=100.00..4324.86 rows=77662 width=27) (actual time=2.018..376.510 rows=77662 loops=1)
-> Hash (cost=38068.19..38068.19 rows=5431 width=89) (actual time=422.560..422.560 rows=5431 loops=1)
Buckets: 8192 Batches: 1 Memory Usage: 742kB
-> Gather (cost=5376.97..38068.19 rows=5431 width=89) (actual time=173.080..419.779 rows=5431 loops=1)
Workers Planned: 4
Workers Launched: 4
-> Hash Join (cost=4376.97..36525.09 rows=1358 width=89) (actual time=175.150..379.921 rows=1086 loops=5)
Hash Cond: (p1.npp = f.npp)
-> Parallel Seq Scan on e1point p1 (cost=0.00..31025.21 rows=295821 width=40) (actual time=3.167..119.309 rows=236657 loops=5)
-> Hash (cost=4309.09..4309.09 rows=5431 width=49) (actual time=156.633..156.633 rows=5431 loops=5)
Buckets: 8192 Batches: 1 Memory Usage: 499kB
-> Hash Join (cost=1907.79..4309.09 rows=5431 width=49) (actual time=115.947..148.795 rows=5431 loops=5)
Hash Cond: (ec.npp = f.npp)
-> Seq Scan on g3ecologie ec (cost=0.00..2057.90 rows=77090 width=30) (actual time=3.085..51.858 rows=77090 loops=5)
-> Hash (cost=1839.90..1839.90 rows=5431 width=19) (actual time=44.989..44.989 rows=5431 loops=5)
Buckets: 8192 Batches: 1 Memory Usage: 340kB
-> Seq Scan on g3foret f (cost=0.00..1839.90 rows=5431 width=19) (actual time=2.588..39.368 rows=5431 loops=5)
Filter: (numboite IS NOT NULL)
Rows Removed by Filter: 71659
-> Hash (cost=7996.44..7996.44 rows=10 width=24) (actual time=0.547..0.547 rows=7 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Foreign Scan on abmode mpro (cost=100.00..7996.44 rows=10 width=24) (actual time=0.540..0.541 rows=7 loops=1)
-> Hash (cost=7996.44..7996.44 rows=10 width=24) (actual time=0.401..0.401 rows=5 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Foreign Scan on abmode mpr (cost=100.00..7996.44 rows=10 width=24) (actual time=0.396..0.396 rows=5 loops=1)
-> Hash (cost=20313.31..20313.31 rows=1 width=24) (actual time=1.178..1.178 rows=19 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Foreign Scan (cost=100.00..20313.31 rows=1 width=24) (actual time=1.168..1.170 rows=19 loops=1)
Relations: (metaifn.abmode mhum) INNER JOIN (metaifn.abgroupe ghum)
-> Hash (cost=7996.44..7996.44 rows=10 width=24) (actual time=0.698..0.698 rows=86 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 13kB
-> Foreign Scan on abmode mser (cost=100.00..7996.44 rows=10 width=24) (actual time=0.668..0.681 rows=86 loops=1)
-> Hash (cost=7996.44..7996.44 rows=10 width=24) (actual time=0.627..0.627 rows=10 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Foreign Scan on abmode mtop (cost=100.00..7996.44 rows=10 width=24) (actual time=0.618..0.618 rows=10 loops=1)
-> Hash (cost=7999.46..7999.46 rows=161 width=24) (actual time=0.896..0.896 rows=166 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 17kB
-> Foreign Scan on abmode mroc (cost=100.00..7999.46 rows=161 width=24) (actual time=0.570..0.852 rows=166 loops=1)
Planning time: 14.370 ms
Execution time: 3093.657 ms
(67 lignes)
Dans le plan initial, il me semble que c'est au niveau de ce nœud que ça coince :
-> Foreign Scan (cost=100.00..20313.31 rows=1 width=24) (actual time=1.261..1.266 rows=19 loops=1)
Relations: (metaifn.abmode mhum) INNER JOIN (metaifn.abgroupe ghum)
En effet, le planificateur voit une seule ligne là où il y en a en réalité 19, et du coup il privilégie à tort le nested loop.
J'ai pourtant fait un ANALYZE de toutes mes tables (y compris étrangères) pour avoir des stats le plus à jour possible...
Voyez-vous une explication et un moyen d'améliorer le plan d'exécution, sans désactiver le paramètre enable_nestloop ?
Je précise que cette requête sera utilisée pour créer une vue. Il faut donc que son temps d'exécution reste acceptable (surtout vu le nombre de lignes en jeu)...
Merci d'avance pour votre aide et pardon pour la longueur du message,
Cédric
#21 Re : Général » Colonne geom en clair » 08/02/2018 14:36:02
Bonjour,
C'est l'inverse qu'il faut écrire :
UPDATE Ma_Table
SET geometrie = st_astext(geom);
#22 Re : Réplication » [RESOLU] replication master to master » 07/02/2018 08:29:48
Pour BDR, c'est la 9.4 qui nécessitait d'être patchée. Mais en 9.6, c'est juste une extension de PostgreSQL, avec toute la simplicité d'installation que ça représente.
#23 Re : Réplication » [RESOLU] replication master to master » 06/02/2018 14:14:38
Bonjour,
Il y a aussi BDR qui propose une réplication maître / maître, il me semble.
#24 Re : Général » importation d'une feuille Excel en csv dans postgres » 04/12/2017 11:19:45
Bonjour,
La première erreur peut être due au fait que sous Excel, le séparateur décimal est la virgule, alors que pour PostgreSQL c'est le point.
Il faut donc être vigilant à ce point lors de l'export au format CSV...
#25 Re : Général » PostgreSQL restauration à un état antérieure » 06/10/2017 17:30:24
Bonjour,
Dans votre description, je n'ai vu à aucun moment une quelconque mention à une copie initiale des fichiers de données (basebackup). Pourtant, c'est à partir de cette copie qu'on restaure les données en rejouant les fichiers WAL.
Sans ça, pas de restauration possible...$
Avez-vous effectué un ou plusieurs basebackup ?