Vous n'êtes pas identifié(e).
Pages : 1
Bonjour tout le monde,
Après avoir mis en place foreign_data_wrapper sur postgresql, Je rencontre un énorme lenteur sur l'exploitation des tables. Le temps de réponse de select sur des petite tables est multiplié par *5 voir par *10.
Le problème c'est que les foreign tables n'ont ni clé primaire ni index et je suis désolé de dire que je ne sais pas comment créer une clé voir un index sur foreign table.
l'ordre de creation de foreign table n'accepte pas le (CONSTRAINT) et je suis à court d'idées. 
--
voici quelques infos:
--------------------------------------------------------------------------------------------------------------
PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit
--
plan d'exécution select count(*);
===
table réelle:
=========
explain analyze select count(*) from accord;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------
Aggregate (cost=31.00..31.01 rows=1 width=0) (actual time=3.473..3.474 rows=1 loops=1)
-> Seq Scan on accord (cost=0.00..27.60 rows=1360 width=0) (actual time=0.026..1.823 rows=1360 loops=1)
Total runtime: 3.581 ms
(3 rows)
=======
foreign table:
===========
explain analyze select count(*) from accord;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------
Aggregate (cost=220.92..220.93 rows=1 width=0) (actual time=11.130..11.132 rows=1 loops=1)
-> Foreign Scan on accord (cost=100.00..212.39 rows=3413 width=0) (actual time=2.786..9.258 rows=1360 loops=1)
Total runtime: 37.167 ms
(3 rows)
==>
Merci d'avance pour votre aide.
Hors ligne
Est ce que quelqu'un pourras m'aider ou m'aiguiller SVP?
Hors ligne
Il n'est pas possible de créer un index sur une foreign table. Il faut la créer sur la table locale (ceci dit, ça ne servira à rien pour un count(*) sur une foreign table).
Guillaume.
Hors ligne
Merci Guillaume,
le count(*) n'est qu'un exemple.
Est ce que je sous entend que si on crée un index sur une table (toto) en locale est bénéfique pour l'exploitation de la foreign table?
Bien à toi
Hors ligne
Si le FDW est assez intelligent, oui.
Guillaume.
Hors ligne
Est il possible de le rendre intelligent et Comment?
Hors ligne
Bonjour tout le monde,
Je suis vraiment dans une impasse et je suis à court d'idées, donc si quelqu'un pourra m'aiguiller ça sera sympa.
Bien à vous
Hors ligne
Le principal problème semble être la bande passante entre vos deux serveurs. Savez-vous le type de lien entre ceux-ci ? La bande passante disponible ainsi que la latence ?
SInon avez-vous regardé la documentation de postgres_fdw ? http://docs.postgresql.fr/9.3/postgres-fdw.html Vous avez notamment le paramètre use_remote_estimate qui peut être utile si les statistiques sont à jour sur la tables du serveur distant mais qu'aucun analyze n'a été fait sur la foreign table.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Merci rjuju d'avoir redonner vie à mon post.
Tu pourras me dire le valeur qu'il faut mettre: true or false.
Merci d'avance.
Hors ligne
Pour le paramètre use_remote_estimate, idéalement il faut le laisser à false et exécuter des analyze sur la foreign table. Le mettre à true permet d'utiliser les statistiques de la vraie table, mais cela implique un coût supérieur (des explain seront effectués). La vraie réponse est donc d'avoir une politique de maintenance correcte.
Julien.
https://rjuju.github.io/
Hors ligne
J'ai lu attentivement la doc officiel de la page que tu m'as communiqué (merci).
Mon problème initiale c'est le temps de réponse des requêtes SQL lancé sur la base ou les tables sont "wrappées", quand je lance la même requête (exactement la même) sur les tables d'origine du serveur maître j'ai un rapport de 10 voir plus sur le temps de réponse. (voir exemple)
==
Table d'origine
=========
explain analyze select pays_id, accord_groupe_id from dw_fait_indice_net where pays_id = '82';
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------
Seq Scan on dw_fait_indice_net (cost=0.00..92.90 rows=1352 width=16) (actual time=0.017..0.913 rows=1352 loops=1)
Filter: (pays_id = 82::bigint)
Total runtime: 1.138 ms
(3 rows)
====
Foreign table:
=========
Foreign Scan on dw_fait_indice_net (cost=100.00..219.94 rows=1352 width=16) (actual time=2.486..20.993 rows=1352 loops=1)
Total runtime: 21.642 ms
(2 rows)
Du coup avec des requêtes plus compliquées le temps de réponse risque d'être interminable.
Est ce qu'il y a un moyen de réduire ce coût? sachant que je ne peut pas créer d'index.
Hors ligne
Avant d'aller plus loin, il faut savoir quelle est la capacité du réseau entre ces deux machines, en terme de bande passante et de latence.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Voici les tests fait:
ifconfig eth0 | grep -Eo "MTU:[0-9]+"
MTU:1500 ==> Pour les deux machines donc latence 7,7772ms
==
dd if=/dev/zero of=test bs=100M count=1; scp test usertest@xxxxx1:/dev/null;
1+0 records in
1+0 records out
104857600 bytes (105 MB) copied, 0.297704 s, 352 MB/s
test 100% 100MB 50.0MB/s 00:02
===========
Est ce que je devrai fournir d'autres metriques?
Bien à toi
Hors ligne
Je ne vois pas comment vous pouvez comparer les deux, ce n'est pas du tout la même chose. En local, vous ne faites qu'exécuter la requête. À distance, vous devez faire la connexion au serveur distant, exécuter la requête, récupérer les données, fermer la connexion. C'est évidemment plus long. L'intérêt d'un FDW n'est pas sa rapidité, c'est plutôt d'aller récupérer des données qu'on ne pourrait pas avoir autrement. Et d'accepter en échange de cet intérêt des performances qui sont moindres sur ce type d'objet.
Guillaume.
Hors ligne
Si effectivement le temps de réponse est un problème, il faudrait envisager une autre solution comme de récupérer les données distantes via un ETL pour les avoir en local (en fonction de vos usages bien sur).
Hors ligne
Bonjour,
Merci pour les réponses et l'aide que vous m'avez apporté. Pour (gleu), je sais bien que le temps de réponse ne soit le même, ce que j'essaye c'est d'optimiser ce temps là le maximum (si c'est possible bien sûre). Pour (uruvela), le choix d'un ETL est judicieux le seul problème c'est que la MAJ des donnée ne soit pas au temps réel.
Merci encore à vous et j'attend l'avis de rjuju.
Hors ligne
Je suis de l'avis des autres. Vous aurez un temps minimum d'exécution bien supérieur du à la connexion/déconnexion et la latence du réseau. Et sans connaître votre besoin, difficile de dire si l'utilisation d'un foreign data wrapper est la meilleure solution.
Julien.
https://rjuju.github.io/
Hors ligne
Le besoin initial est d'avoir un serveur Postgresql pour le reporting. Une architecture de hot-standby à été mise en oeuvre master/slave. Le reporting s'effectue sur l'esclave. Le problème c'est que l'application de reporting fait "CREATE UNLOGGED table from t1, join, where...", comme sur l'esclave ce n'est pas possible de faire des DDL on a choisit de faire une base avec FW pour le besoin de l'appli. Voila l'origine du problème.
Bien à toi
Hors ligne
Si vous voulez des performances, utilisez Slony.
Guillaume.
Hors ligne
Les unlogged tables sont crées afin d'effectuer plusieurs requêtes sur celles-ci avant d'être détruites ou s'agit-il d'une solution pour facilité l'écriture des requêtes ?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Si vous faites du reporting sur l'esclave et que vous n'avez pas besoin des données à jour en temps réel (par exemple j-1) vous pouvez toujours créer un deuxième esclave que vous activez (en read/write) pour votre application de reporting.
Cordialement,
Cordialement,
Sébastien.
Hors ligne
Pages : 1
