Bonjour,
Si vous lisez l'anglais, il y a un article sur ce sujet, que je trouve très pédagogique, dans le numéro d'août de BSD Magazine, qui peut être téléchargé ici:
http://bsdmag.org/magazine/1809-tuning-zfs-on-freebsd

Merci pour la réponse.
Je sais que c'est le répertoire principal qu'il faut donner. Mais ma question concerne la migration des données n'étant pas dans ce répertoire principal.
Pour prendre un exemple concret, mon répertoire principal actuel est "/disk2/pgsql/9.0/data", mais j'utilise 2 autres tablespace qui ont pour emplacements /disk3/pgsql/9.0/data et /disk4/pgsql/9.0/data

La logique , telle que j'ai comprise,  est d'appeler pg_upgrade avec les paramètres --old-datadir=/disk2/pgsql/9.0/data et --new-datadir=/disk2/pgsql/9.2/data. Et j'aurais bien les données migrée du répertoire principal dans /disk2/pgsql/9.2/data. Mais que ce passera-t-il pour les 2 autres répertoires ? Va-t-il migrer les données de /disk3/pgsql/9.0/data, m'empêchant ainsi tout downgrade ultérieur ? Va-t-il échouer en considérant que le répertoire n'est pas vide et contient des données d'une version incompatible ?

Dans l'esprit, il semblerait logique de vouloir dire que les données de /disk3/pgsql/9.0/data seront migrées dans /disk3/pgsql/9.2/data et celles de /disk4/pgsql/9.0/data dans /disk4/pgsql/9.2/data. Mais, si j'ai compris la doc, pg_upgrade ne permet pas cela. C'est même encore plus simple, la problématique des tablespaces n'est pas évoquée dans le manuel de pg_upgrade, d'où ma question.

Aïe ! Pas cool ça !
A vrai dire, avant de migrer mon serveur en version 9, ma BDD était "encodée" (si on peut dire !) en SQL_ASCII, ce qui me posait d'autres soucis dans la mesure ou les tris étaient sensibles aux accents. Par contre, tous les caractères étaient bien pris en compte.

Bon, tant pis, je vais contourner le problème au niveau applicatif.

En tous cas, merci pour votre réponse.

Comme je le dis dans mon précédent post, ils sont tous à leur valeur par défaut; plus précisément, tous les paramètres concernant l'autovacuum sont "commentarisés" sauf autovacuum=on

Par ailleurs, parmi les processus actifs (au sens système), j'ai un processus "postgres: autovacuum launcher process" qui tourne.

Le résultat d'Explain analyse est le suivant:

"Aggregate  (cost=3735.82..3735.83 rows=1 width=0) (actual time=3460.170..3460.171 rows=1 loops=1)"
"  ->  Seq Scan on presse_pdf_contenu  (cost=0.00..3665.51 rows=28122 width=0) (actual time=0.377..3446.645 rows=27890 loops=1)"
"        Filter: (pres_pdf_contenu_vecteur @@ '''seanc'''::tsquery)"
"Total runtime: 3460.248 ms"

La base est sous PostgreSQL 9.0.1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit   

Et votre analyse était la bonne; en effet, si je change la 1ère requête pour une recherche plus restrictive, alors l'index est bien utilisé:

Exemple:

SELECT *
FROM
    presse_pdf_contenu
WHERE
    pres_pdf_contenu_vecteur @@ to_tsquery('fr','france & allemagne & algerie')

"Bitmap Heap Scan on presse_pdf_contenu  (cost=29.10..37.03 rows=2 width=49) (actual time=19.460..20.743 rows=778 loops=1)"
"  Recheck Cond: (pres_pdf_contenu_vecteur @@ '''franc'' & ''allemagn'' & ''alger'''::tsquery)"
"  ->  Bitmap Index Scan on idx_presse_vecteur  (cost=0.00..29.10 rows=2 width=0) (actual time=19.381..19.381 rows=778 loops=1)"
"        Index Cond: (pres_pdf_contenu_vecteur @@ '''franc'' & ''allemagn'' & ''alger'''::tsquery)"
"Total runtime: 20.966 ms"

SELECT *
FROM
    presse_pdf_contenu
WHERE
    pres_pdf_contenu_vecteur @@ to_tsquery('fr','france & allemagne')

"Seq Scan on presse_pdf_contenu  (cost=0.00..3665.51 rows=412 width=49) (actual time=0.051..2404.342 rows=6639 loops=1)"
"  Filter: (pres_pdf_contenu_vecteur @@ '''franc'' & ''allemagn'''::tsquery)"
"Total runtime: 2406.538 ms"

Merci pour cette information. J'ai encore beaucoup de choses à apprendre ... ;-)

Merci pour cette réponse extrêmement rapide.

La table compte environ 90 000 lignes. Elle "pèse" 7Mo, et l'index 1.8Go. A côté, j'ai aussi l'indication "Taille de la table TOAST: 21Go", mais je ne sais pas ce que c'est ;-)

Enfin, le explain analyse retourne:

"Seq Scan on presse_pdf_contenu  (cost=0.00..3665.51 rows=28122 width=49) (actual time=0.111..2344.661 rows=27890 loops=1)"
"  Filter: (pres_pdf_contenu_vecteur @@ '''seanc'''::tsquery)"
"Total runtime: 2352.961 ms"

Encore merci pour la réponse

Bonjour,

Interpellé par ce thread, j'ai jeté un coup d'oeil à mon propre fichier de configuration (sous CentOS).
J'y lis des valeurs telles que:

- shared_buffers = 7680MB
- maintenance_work_mem = 1GB

etc...

A priori, ces paramètres avec unités semblent licites et, sous réserve que ce soit bien la cas, moins sujet à erreurs d'interprétations que des simples valeurs numériques

Il s'agit d'un back-office, dont l'accès de ne concerne que quelques personnes (j'ai plus de serveurs que d'utilisateurs dans ce cas ;-) ). La montée en charge est donc un problème qui ne se pose pas.

Par ailleurs, je me permets 2 petites remarques:
1- on ne choisit pas toujours ni son environnement de travail, ni son langage, ni son framework, surtout en entreprise.
2- un projet qui vit peut évoluer vers des directions non prévues initialement. Du coup, un choix judicieux à un instant donné peut, dans certaines circonstances, s'avérer partiellement ou totalement malheureux. Ce n'est pas pour autant (par exemple pour rajouter ue fonctionnalité), que l'on remet systématiquement par terre des années de développement. Tout ça pour dire que ces jugements péremptoires,  s'ils peuvent être exacts en théorie, n'ont aucun sens face à des situations rélles qui sont toutes par définition des cas particuliers. Mais bon, je le sais, la mode est aux donneurs de leçons...

C'était bien évidemment mon premier réflexe.

Malheureusement, ce n'est pas si simple que cela. En effet, mon interface est "Full Ajax" (basée sur la librairie extJS) et les différentes requêtes sont donc appelées via des scripts distincts, appelés de façon asynchrone. Or, visiblement, à la fin de chaque script, un COMMIT (en l'occurrence un AUTO-COMMIT donc) est réalisé.

Si j'appelle à la fermeture de ma pseudo-fenêtre (via un nouvel appel AJAX) un "simple" Rollback, rien ne se passe, puisque tout a déjà été commité (normal !)

D'où ma question: est-il possible de désactiver provisoirement l'autocommit ?

Etant donné le fruit de mes recherches, et les premières réponses fournies ici, je crains le pire...
Pourtant, cette fonctionnalité a existé par le passé, et je m'étonne de tomber sur une régression, aussi motivée soit-elle. PostgreSQL ne nous avait pas habitué à cela...

Super, merci !
Le mot-clé qui me manquait pour que ma recherche aboutisse est donc...trigramme

Ca ne s'invente pas !

Je vais voir ça de plus prêt, les perspectives étant particulièrement intéressantes.

Effectivement, la colonne peut être grosse; elle contient le contenu de fichiers bureautiques qui peuvent aller jusqu'à plusieurs centaines de pages !

Et je confirme ce que vous dites: la fonction n'est bien appliquée QUE sur les enregistrements retournés.

Du coup, je m'en suis tiré avec une "pirouette" consistant:

1- A appeler la rechercher sans le ts_headline, afin de pouvoir afficher les résultats immédiatement
2- Appel de la fonction ts_headline en asynchrone (via Ajax) pour remplir dans un 2ème temps les extraits des documents.

Le code est plus lourd, génère plus de requetes HTTP et est moins satisfaisant pour l'utilisateur, mais c'est un compromis permettant un affichage des résultats rapide.

Merci pour votre aide.

Ne reste plus qu'à espérer qu'une prochaine version améliorera les performances de cette fonction (qui, dans l'état actuel, sont, il faut bien le reconnaitre- assez médiocres)