Bonjour,

Concernant les logs, je vous propose de jouer les commandes suivante :

mkdir /pghome/data/pg_log (pghome chez moi est /usr/local/pgsql)
chown postgres:postgres /pghome/data/pg_log -R

Et ajouter ceci dans la fin de votre fichier /pghome/data/postgresql.conf
#Paramètrage des logs
log_destination  = 'stderr'
redirect_stderr  = on
log_directory  = 'pg_log'
log_filename  = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_rotation_age  = 1d
log_rotation_size  = 100MB
client_min_messages  = warning
log_connections  = on
log_disconnections  = on

Relancez ensuite postgres et postez le contenu du fichier qui sera dans le répertoire /pghome/data/pg_log il sera sans doute plus facile de vous répondre.

Merci pour votre aide.
Je vais donc laisser autovacuum_analyze_scale_factor  = 0.2 dans mon fichier de propriété.
Je ferai aussi une ligne dans pg_autovacuum pour chacune des grosses tables manipulées par l'application avec scale_factor à 0 et fréquence d'analyse et vacuum respectivement à 5000 et 10.000 lignes modifiées.
J'ai par contre abaissé à 100 le set statistics car j'ai constaté une grosse montée de l'utilisation de mon file system avec le set statistics à 500 (nettement moindre mais tout aussi performant à 100).

Bonjour,

La différence est énorme, avec un SET STATISTICS à 500 sur mon index, l'analyse est 2 fois plus lent mais la requête ne prend plus que 469ms.
Un tout grand merci pour le coup de main.

Une dernière question, concernant l'analyse, puis-je mettre autovacuum_analyze_scale_factor à 0?

Merci pour ces renseignements...
Je vais encore abuser mais comment fait-on une configuration particulière pour une table?

Bonjour,

Merci pour l'intérêt porté à ma question.

L'explain analyse donne ceci :

Unique  (cost=1900115.33..1919800.62 rows=1312353 width=36) (actual time=327436.701..327446.455 rows=855 loops=1)
  ->  Sort  (cost=1900115.33..1903396.21 rows=1312353 width=36) (actual time=327436.691..327439.849 rows=864 loops=1)
        Sort Key: lm_action.origin, lm_action.entry_key, lm_action.pkey, lm_action.creation_ts, lm_action.polhid
        ->  Hash Join  (cost=886494.66..1735996.83 rows=1312353 width=36) (actual time=310684.445..327431.949 rows=864 loops=1)
              Hash Cond: (lm_status.action_key = lm_action.pkey)
              ->  Bitmap Heap Scan on lm_status  (cost=176955.22..794709.68 rows=11597756 width=8) (actual time=100966.826..279975.553 rows=10740857 loops=1)
                    Recheck Cond: (status = ANY ('{2,1}'::integer[]))
                    Filter: (inactif_uid IS NULL)
                    ->  Bitmap Index Scan on idx_lm_status_status  (cost=0.00..174055.78 rows=11656037 width=0) (actual time=100895.813..100895.813 rows=10854635 loops=1)
                          Index Cond: (status = ANY ('{2,1}'::integer[]))
              ->  Hash  (cost=632301.26..632301.26 rows=3802495 width=36) (actual time=73.277..73.277 rows=897 loops=1)
                    ->  Bitmap Heap Scan on lm_action  (cost=89929.49..632301.26 rows=3802495 width=36) (actual time=0.909..58.674 rows=897 loops=1)
                          Recheck Cond: (entry_key = ANY ('{3974400,3958028,3940355,3940309,3917969,3911509,3888821,3870523,3862873,3816029,3804693,3799560,3799546,3799542,3794777,3782636,3771277,3771233,3771222,3764226,3764147,3764136,3764130,3764125,3764121,3754407,3754396,3748869,3744775,3744774,3744772,3744771,3744764,3744758,3744742}'::bigint[]))
                          Filter: (inactif_uid IS NULL)
                          ->  Bitmap Index Scan on idx_lm_action_entry_key  (cost=0.00..88978.86 rows=4917019 width=0) (actual time=0.853..0.853 rows=1215 loops=1)
                                Index Cond: (entry_key = ANY ('{3974400,3958028,3940355,3940309,3917969,3911509,3888821,3870523,3862873,3816029,3804693,3799560,3799546,3799542,3794777,3782636,3771277,3771233,3771222,3764226,3764147,3764136,3764130,3764125,3764121,3754407,3754396,3748869,3744775,3744774,3744772,3744771,3744764,3744758,3744742}'::bigint[]))

J'ai aussi vérifié les vacuum et le dernier date de moins de 12h.

Existe-t-il un petit programme qui permette d'interpréter les valeurs retournées par l'explain analyse facilement?

Les 2 OS sont en 32 bits (les CPU permettent le 64 mais le client avait déjà des licences pour du 32).
Je re-essaierai dès que possible l'intégralité de la procédure (de l'archivage du data à sa restauration dès que possible mais le client dispose d'une DB de 35 giga et c'est coton à copier...)
En tout cas, merci pour les avis...

2 tentatives sur l'opteron et 2 fois le même résultat...
Vous parlez d'erreur temporaire, s'agit-il d'une heure légèrement différentes sur les 2 serveurs?

Je viens de comparer les 2 fichiers de log et ils sont identiques, au nom des machines près...
Ce qui me semble plus étrange, c'est que j'ai pu restaurer ce data sur un autre serveur intel, avec postgres 8.2.14 et je n'ai pas le moindre soucis de séquence.
Je suis assez perplexe, les machines sont fort semblables (sauf cpu). Les partitions sont en ext3 sur les 3 machines, c'est assez inattendu...

J'ai utilisé gcc dans les 2 cas et compilé comme suit :
tar –xjvf postgresql-8.2.12.tar.bz2
cd /root/install/postgresql-8.2.12
./configure
make
make install