Pourriez-vous donner la définition précise des 2 tables (les ordres de création par exemple) ?

pg_ctl reload est une commande, pas un fichier
http://docs.postgresqlfr.org/9.1/app-pg-ctl.html
Si vous avez redémarré le serveur, normalement les modifications sont prises en compte.

Tout est expliqué ici : http://docs.postgresqlfr.org/9.1/runtim … gging.html

Sinon, pour aller vite, si tu veux loguer les requêtes SQL, il faut mettre log_statement à 'all'.
Si tu as plusieurs utilisateurs, log_connections et log_disconnections sont utiles....

Enfin, n'oubliez pas de recharger la configuration :
envoi d'un SIGHUP à postmaster, ou bien pg_ctl reload :
http://docs.postgresqlfr.org/9.1/app-pg-ctl.html

Si c'est juste pour apprendre à l'utiliser (créer des tables, écrire des requêtes, gérer les utilisateurs), je pense que
Windows est largement suffisant. Ça vous prendra moins de temps, à moins que vous connaissiez très bien Linux et pas du tout Windows.
Personnellement, j'ai dû faire la même chose il y a quelques années (installer une base pour apprendre à m'en servir, dans le but de monter une formation Java...). Bien que n'étant pas (mais alors pas du tout) fan de Windows, j'ai fini par installer ma base sous Windows (poste de travail pro sous Windows). Parce que c'était plus simple (pas besoin de serveur distant, ni de monter une machine virtuelle qui bouffait mes ressources système).

Enfin, c'est vous qui voyez.
Si vous avez des questions sur des concepts que vous ne comprenez pas, demandez...
Si vous ne connaissez pas du tout les bases de données relationnelles, je vous conseille de vous procurer un livre. J'avais vu celui-là qui a l'air pas mal :
http://www.google.com/url?sa=t&rct=j&q= … -6imAvu6kw
mais il semblerait qu'il vaut mieux connaître un petit peu le SQL avant de commencer.
Je ne peux vous conseiller de livre pour débutant total, ceux que je connais s'adressent à des connaisseurs, ou des étudiants très motivés (ils sont très théoriques)

Sinon, dans la documentation de PostgreSQL, il y a un tutoriel :
http://docs.postgresql.fr/9.2/tutorial-sql.html
Il n'est pas mal fait, vous pouvez sans doute débuter avec.

Si on suppose que le modèle est bon,

en fait le plan ne me paraît pas déconnant : on a d'un côté une table pi, filtrée par la condition AND, et il reste 10839 lignes filtrées.
En face, la table ln_pi fait 5 millions de lignes apparemment. Donc elle est beaucoup plus grosse.
Si on regarde l'index scan sur ln_pi, c'est bien cela qui prend le plus de temps (15 ms par accès, multiplié par 10 800 lignes....).
Essayez donc ce que conseille rjuju et kenrio (augmenter shared_buffers ), ça pourrait changer la donne...

Je ne vois pas de clé primaire dans les définitions. Elles sont où? 

De plus, qu'est-ce que cela représente?

J'ai l'impression que le modèle n'est pas bon : à quoi sert la 2ème table (ln_putative_inparalog_sequence   ). Que représente sequence? Est-ce le même pour les 2 tables?
(je pense que les index ne sont pas les bons, mais pour cela il faut comprendre ce que représentent les tables)

On dirait qu'il manque un index sur tables_adresses.adresses_01.id
Ça permettrait déjà d'éviter la lecture séquentielle de tables_adresses pour ne ramener que 2924 lignes pour la première requête et... zéro pour l'autre.

C'est plus compréhensible.
Mais quel est l'intérêt de créer des lignes dans la table "mammifère"? Quelles valeurs voulez-vous mettre dans ces lignes au moment où vous les créez ?

Et en travaillant sur les logs? (en loguant tous les ordres SQL et en passant dessus un script ou un programme)
La difficulté que je vois ce sera le volume de log généré (suivant l'activité de la base) et comment gérer les compteurs et les fichiers de log pour ne pas relire à chaque fois les fichiers.

Mais sinon, au niveau applicatif, si c'est possible c'est sans doute le plus simple (si une seule application, et qu'il y a une couche d'accès qui va bien)

C'est donc bien ce que je pensais : la parallélisation n'est pas faite suivant les bons critères.
Il vaudrait mieux paralléliser suivant les lignes de la table A. Comme cela, pas de mises à jour concurrentes entre les transactions, et pas besoin de faire des locks qui rendraient la parallélisation inutiles.

En plus, d'un point de vue de développeur, c'est bien plus souple (il est facile de changer le critère de découpage des lignes de A, voire supprimer la parallélisation si cela s'avère plus efficace au final).

Au passage, A, B et C sont bien dans la même base?

Personnellement, je pense que tout cela est bien compliqué et surtout je ne comprends absolument pas votre besoin de "convertir" l'index en base64, et de le stocker. Si l'index_base64 est calculé à partir de l'index, il vaut mieux ne pas stocker les 2 (vous n'êtes pas en première forme normale dans ce cas...)
Pourriez-vous expliquer ce que vous voulez faire réellement? À quoi sert tout ce micmac?