Déjà il ne peut utiliser aucun index... est-ce que c'est normal?
Il n'y a en particulier pas d'index sur keep_persohoraires.numero_tec. Peut-être qu'avec cet index il pourrait utiliser un plan différent?

Comme a dit Marc (vos messages se sont peut-être croisés), cela n'a pas d'importance pour votre cas.
Par contre, si votre fichier s'appelle sim.csv, donnez bien le nom avec l'extension (par exemple C:/sim.csv). Ce sera le cas pour toute commande, même sous Windows.

Il n'y a pas d'autre driver Postgresql dans le Classpath?

Pourriez-vous mettre un peu plus de code que juste ces 2 lignes (on ne sait jamais...)? Notamment les lignes avant l'insertion, et avant la récupération en base (la requête, etc...)

Et quelle version de la base de données, quelle version du driver JDBC?

J'ajouterai juste que le manuel existe aussi en Français.
Pour les développeurs, si c'est du JEE, il y a peu de choses à savoir (les types de données et notamment l'utilisation du Serial, la gestion des transactions et des niveaux d'isolation, éventuellement la gestion des droits, l'outil COPY, psql pour les personnes plus spécifiquement en charge des données).
Les 2 premiers livres que tu cites ont l'air bien pour des DBAs, mais pas du tout pour des développeurs. Je ne pense pas qu'il existe quelque chose de ce niveau pour développeurs (mais encore une fois, pour du JEE, pas besoin d'un livre de 300 pages, sauf s'ils ne connaissent pas du tout les bases de données relationnelles).
Je conseillerai de leur faire lire la doc d'introduction sur la première page du site (c'est d'ailleurs pour cet usage que je l'ai écrite, car je n'ai rien trouvé pour des développeurs), plus les chapitres de la documentation qui les concernent en priorité ma liste ci-dessus).

SQLPro, je pense que l'entité famille est inutile dans votre modèle : elle ne représente rien (les relations familiales sont portées par le bas du schéma).
Sa seule fonction est de remplacer une chaîne de caractères par une clé technique... C'est probablement aussi inutile que de faire la même chose sur les prénoms, ou sur les dates de naissance. Quant à l'orthographe du nom, il est très probable qu'une erreur soit faite sur le nom d'une personne : par exemple 'Dupont' à la place de 'Dupond'. Et lorsqu'on corrige le nom de Jean, on ne veut pas modifier du même coup le nom de Jacques, qui doit rester 'Dupont'. Je ne parle même pas des noms étrangers qui sont transcrits différemment selon l'officier d'Etat Civil...
Enfin bref cela complique seulement les choses (travail de conception et de développement plus compliqué et plus risqué, jointures supplémentaires...). Pour quel gain?
De plus, on n'a pas besoin de cela pour être en 3ème forme normale : L'attribut nom dépend bien uniquement de la personne.

Ce n'est pas un peu risqué de modifier le pg_hba.conf afin que le mot de passe ne soit pas demandé?
(à moins que ce soit juste une base de test ou de développement, ce qui me parait peu probable dans le cas de ninja21a...)

Pour faire avancer le schmilblick : quel système d'exploitation? Comment avez-vous installé? (compilation, installeur? il y a, à part pour Windows, plusieurs manières de le faire).

Flo

Et quand on fait le truncate, est-ce que la séquence repart au début? ou faudra-t-il la réinitialiser manuellement?

Curieux. Vous n'avez pas de base de test ou de pré-production pour faire des tests plus approfondis? À moins que vous ne parliez déjà d'une telle base?
Les seules raisons que je vois pour cela sont :
1. vous ne passez pas les mêmes paramètres que votre application.
2. lorsque vous effectuez la requête "à la main", les conditions sont différentes : données en cache, statistiques plus à jour...

Evidemment, ce n'est pas long.
Question con, mais on ne sait jamais : vous avez le code de l'application? Vous êtes certain que c'est bien une requête unitaire qui est aussi longue, et non un traitement qui exécute une requête en boucle? (Je ne connais pas votre rôle, votre niveau d'expérience, etc... et ce sont des choses que j'ai déjà vues)
Autre question : vous avez tenté de faire l'insert à la main également? Parce que là, vous ne savez pas ce  qui pose problème, et vous risquez de partir sur une fausse piste.

La priorité pour vous, à mon avis, est soit d'isoler le problème. En fonction de votre rôle, de vos autorisations, vous pouvez soit commencer par prendre le problème du côté de l'application : que fait-elle exactement? regardez le code, les traces, ajoutez des timer dans les logs. Soit suivre le conseil de gleu et utiliser auto_explain. Si vous n'avez pas le droit d'ajouter des modules en production, faites-le en préproduction, ou recette, ou développement, du moment que vous arrivez à avoir le même volume de données, et le même environnement (insertion, purges, vacuum...)

Lorsque vous reviendrez sur le forum, essayez également d'être plus précis :
donnez le texte de votre requête, la description des tables impliquées (colonnes, index, contraintes) dans la requête, ainsi que la description précise des 2 autres requêtes dont vous parlez : celle d'insertion des données acquises et celle de purge (sur quelles tables travaillent-elles? À quelle fréquence?). Afin de comprendre laquelle fait quoi, sur quelles tables, et quelles sont les tailles respectives des tables. Faites le nécessaire pour repérer si la durée extraordinairement longue se produit à un instant particulier (après la purge? après l'insertion? pendant le vacuum? ...)

De toute manière, il faut absolument que vous arriviez à repérer et recrééer les conditions qui produisent la requête trop longue...

chris0938, si vous ne savez pas où sont les logs de démarrage, allez voir le script de démarrage (/etc/init.d/postgres), vous y trouverez le nom du répertoire de log (dans celui que  j'ai sous les yeux, c'est la variable PGLOG). S'il n'y a rien ou si la date de création du fichier ne correspond pas à votre tentative de démarrage... eh bien vous saurez au moins que ça rate avant d'y écrire (voir le script encore).

Je suppose que c'est parce que cet objet n'implémente pas les bonnes interfaces, ou bien n'est pas de la bonne classe :
http://download.oracle.com/javase/1.4.2 … .Object%29

De toute manière, comment pouvez-vous espérer stocker un arbre, donc une structure pleine de pointeurs, dans une suite d'octets? Même Postgresql n'est pas capable de cette sorte de magie...
Il manque donc une étape de sérialisation avant l'étape JDBC, si c'est vraiment ce que vous voulez faire (mais là c'est du pur Java).

D'autre part, sur le fond de votre problème, je ne comprend pas l'intérêt de mettre cela dans la base. Pourquoi ne pas faire un objet partagé par tous vos threads, résidant en mémoire? (quand vous parlez d'instances, c'est quoi? des processus? des threads?  les changements de l'un doivent se répercuter dans l'autre?)