Equivalent d'un copy to [Résolu]

[gorgonite]

Connaissez-vous un bon moyen de faire l'équivalent de cette commande ?

Code :

\copy (SELECT * FROM Main_View) TO 'toto.csv' delimiter ';' csv

Main_View étant une vue, il semble impossible d'écrire la commande sans la requête entre parenthèse et étant donné qu'il y a quelques millions d'enregistrements, j'aurais le temps de tuer ma machine avant qu'elle n'écrive la première ligne


Je suis sous PostGreSQL 8.3 (mais toutes les aides y compris sur des versions plus récentes m'intéressent)

par avance

[estofilo]

Et en quoi la commande telle quelle ne te convient pas?

[gorgonite]

Envoyé par estofilo

Et en quoi la commande telle quelle ne te convient pas?

Le temps d'exécution

[estofilo]

Ce n'est pas la méthode \copy en soi qui doit être lente, c'est le SELECT. Pour voir si c'est améliorable il faudrait un EXPLAIN du SELECT et les définitions de la vue et des tables sous-jacentes.

[gorgonite]

Envoyé par estofilo

Ce n'est pas la méthode \copy en soi qui doit être lente, c'est le SELECT. Pour voir si c'est améliorable il faudrait un EXPLAIN du SELECT et les définitions de la vue et des tables sous-jacentes.

En gros, c'est une vue sur une table avec des jointures sur des foreign pour afficher le champ textuel correspondant à la dite clé et une jointure sur la clé primaire pour "émuler l'héritage de table". Le choix de la table fille étant également déterminée par un case/when sur un champ. Certaines tables sont utilisées via une fonction d’agrégation pour fusionner en un champ textuel un ensemble de couples (nom, valeur)

Il y a environ 2.5M d'enregistrements sur la table principale.

Actuellement, la requête remplit ma RAM et au bout de 24h, je n'ai toujours aucun résultat... j'ai donc du passer par un script qui fait le travail en 2 étapes, d'abord une requête récupérant les Id, qui sont consommés au fur et à mesure par une requête sur la vue pour cet Id... Au final, il me faut près de 18h pour arriver au bout

[estofilo]

D'après l'explain il y a un tri final. Ca rend effectivement impossible le fait d'avoir des résultats au fur et à mesure. L'ensemble des résultats est matérialisé en espace temporaire, puis trié, puis renvoyé.

Juste en dessous on voit ça:

Hash Join (cost=53.40..302632292689.69 rows=2151999 width=826)

53.40 est le coût estimé pour sortir la 1ere ligne, et 302632292689 le coût pour l'ensemble des lignes.
Donc ce plan indique que la 1ere ligne sortirait tout de suite s'il n'y avait pas le tri.

Je suggèrerais bien de supprimer le ORDER BY du SQL voir ce que ça donne, et si c'est mieux de faire le tri post-SQL à partir du fichier CSV.

Sous Unix, la commande sort ferait l'affaire si le CSV ne comporte pas de champs texte qui s'étalent sur plusieurs lignes.

[gorgonite]

Effectivement, j'avais oublié ce sort... je passe de 18h via un script à 8min en export via psql