Vous pourriez peut-être aller lire cette page de la documentation pour vous éclaircir les idées :
http://docs.postgresql.fr/9.0/tutorial-arch.html

Par rapport à MySQL, il y a également la conférence de Jim Nasby :

http://www.pgcon.org/2010/schedule/events/274.en.html  (slides)
http://www.fosslc.org/drupal/content/on … s-postgres (vidéo)

et une interview du même :
http://www.youtube.com/watch?v=57wvuX4bLHE

Ah oui, en fait comme j'avais toujours vu récupérer les valeurs dans un programme puis fait les opérations sur les chaînes, je n'avais pas pensé que cela pouvait être différent si on le faisait dans le SQL directement.

Mais beaucoup de gens pensent que le délimiteur par défaut est un point-virgule, parce que Excel exporte ses données avec un point-virgule comme séparateur. On n'a  même pas le choix (en tout cas avec la version 2003).
Donc attention à ne pas se faire avoir par le séparateur si le but est d'importer des données provenant d'Excel, ou de programmes conçus par des gens qui pensent que le séparateur est le point-virgule. Je me suis déjà fait avoir

Bonjour,

Pourriez-vous copier ici l'ensemble du fichier ou des ordres passés, en un seul bloc?

Je ne pense pas qu'il soit judicieux de faire cela sous pgadmin: exécuter un script de 600 000 lignes, ce n'est pas franchement interactif. Il vaut mieux utiliser psql pour cela.

Je m'interroge tout de même sur les 600 000 mises à jour : cela fait tout de même beaucoup si c'est dans la même transaction...

Quelqu'un a un avis éclairé sur la capacité de Postgres à gérer une telle transaction?

Et comme  ceci :

select * from  pci.dep13_parcelle_pci  where id_parc ~  E'\\d{5}[A-Z]{1,2}\\d{4}' ;

?

Salut,
Faut que tu regardes dans la doc, ici :
http://docs.postgresqlfr.org/8.4/functi … ching.html
au paragraphe "expressions rationnelles POSIX".
Je pense que c'est ce que tu cherches.

Pour compléter ce que dit Guillaume (je suis nantaise)
Plusieurs grandes sociétés de formation ont des agences à Nantes. Mais mis à part pour les formations fréquemment demandés, les formations en province sont organisées à la demande. C'est-à-dire qu'ils s'efforcent de regrouper, si possible, des stagiaires de différentes entreprises pour organiser des formations. Sinon il faut aller sur Paris.
Il y a aussi des sociétés nantaises, mais... comment dire? Attention à la qualité. J'ai eu de très mauvais retours de certaines. Il y a des sociétés où les formateurs prennent connaissance du sujet juste avant de donner la formation. Alors pour une formation DBA....

Bref, à mon avis, mieux vaut faire l'effort d'un déplacement de quelques jours (effort pour toi ou effort financier pour ta boite), plutôt que de payer une formation de mauvaise qualité (celles où tu te dis que tu aurais fait aussi bien tout seul avec un bouquin ou la doc). D'ailleurs les mauvaises formations sont chères également.

C'était peut-être pas très clair :  certainement que cela fonctionne avec la table presta à la place de la table intervention. Mais il  faut évidemment laisser la clause where, sinon la requête est fausse.

L'autre post était plus une question aux autres membres du forum, pour la "culture", parce que je me demandais s'il n'y avait pas moyen de faire mieux.
Évidemment si la requête avec presta est suffisamment rapide, laissez-la telle quelle.

Par contre je vous conseille tout de même de vous renseigner sur les opérations de maintenance (analyse) au moins en production. Et si vous avez des tests à faire, sur l'environnement où vous faites les tests.

Au fait, merci à tous pour vos conseils. J'ai finalement suivi le conseil de Marc (ETL), et j'ai bien fait je pense. Il y avait une soixantaine de tables à copier, avec des différences de schéma (des colonnes à supprimer), et des conversions de type. On avait oublié de me dire que certaines colonnes des tables de départ ne devaient pas être prises en compte.

J'ai utilisé Pentaho Data Integration (Kettle), et cela m'a pris environ 1 jour (installation, mise en place, test...). Sinon j'aurais fait avec un script bash + une procédure PL/SQL mais je pense que j'y serai encore. En effet il   m'aurait fallu écrire toutes les requêtes d'extraction en vérifiant la liste des champs pour chaque table dans Oracle et dans Postgres, alors qu'avec Kettle on a directement la correspondance entre les colonnes de la table de départ et celle d'arrivée. Je ne sais pas ce que cela aurait donné pour l'encodage...

Sinon, juste une question au cas où quelqu'un connaitrait la réponse : quand on utilise COPY pour charger une table, comment doit être représentée la valeur des booléens? (j'ai pas vu cette info sur la page de doc de la commande COPY)

Sinon, j'ai quand même quelque chose sur la requête : au vu de ce que vous dites, la table intervention qui est jointurée avec les sous-requêtes sert à garantir qu'on puisse avoir toutes les possibilités de la clause Where . En ce sens, faire travailler postgres sur toute la table intervention ne sert à rien, c'est seulement int_refinst qui nous intéresse.

Or ant_refinst est probablement la clé primaire d'une autre table (la table des techniciens?). Je serais vous, je remplacerait sans hésiter la table intervention qui apparait en premier dans la requête par cette table : elle est probablement beaucoup plus petite, et elle évite le DISTINCT (un gros tri en moins...) Si la table contient des identifiants d'autres personnes (des personnes qui ne sont pas techniciens) je tenterait le coup tout de même, en ajoutant le critère qui va bien.

Ca n'empêche pas de regarder si l'ANALYZE a été fait récemment. Au fait, vous travaillez toujours sur l'environnement de développement? On (les développeurs) a souvent tendance à oublier les opérations de maintenance sur les bases de test et de développement...

Au passage, une question pour Guillaume : je suppose que sa table "bouge" beaucoup (création de nouvelles lignes, voire suppressions). Si c'est le cas, il faudrait qu'il s'assure qu'il y a un ANALYZE régulier fait sur la base de prod (voire celle de test) ?