Performances fetchs 3.5M lignes

Bonjour,

C'est mon premier post ici. Alors j'espère que je respecte bien les règles
d'usage.

J'ai une base postgresql 9.0.6 (Backports Debian Squeeze) qui sert une
application Ruby on Rails.

J'ai 3.5M lignes dans une table et 570000 dans l'autre.

Voilà à quoi elles ressemblent :

-- Table: user_magazines (570 000 lignes)

CREATE TABLE user_magazines
(
id serial NOT NULL,
user_id integer,
libelle character varying(255),
/* ... */
CONSTRAINT user_magazines_pkey PRIMARY KEY (id )
);

CREATE INDEX index_user_magazines_on_user_id
ON user_magazines
USING btree
(user_id );

CREATE INDEX index_user_magazines_on_libelle
ON user_magazines
USING btree
(libelle );

et

-- Table: user_parutions (3.5M lignes)

CREATE TABLE user_parutions
(
id serial NOT NULL,
user_id integer,
user_magazine_id integer,
/* ... /
CONSTRAINT user_parutions_pkey PRIMARY KEY (id )
);

CREATE INDEX index_user_parutions_on_user_id
ON user_parutions
USING btree
(user_id );

CREATE INDEX index_user_parutions_on_user_magazine_id
ON user_parutions
USING btree
(user_magazine_id );

Ca c'est moi qui l'ai changé, j'ai cru comprendre que ça pouvait changer
des choses.

ALTER TABLE user_magazines ALTER COLUMN id SET STATISTICS 1000;
ALTER TABLE user_parutions ALTER COLUMN id SET STATISTICS 1000;

J'ai REINDEXé, VACUUMisé, ANALYZé.

Et j'ai ce plan pour cette très bête requête :

production=> explain analyze select um.*, up.* from user_parutions up join
user_magazines um on (um.id=up.user_magazine_id);

Hash Join (cost=41033.68..388209.57 rows=3523087 width=256) (actual
time=1033.790..57197.418 rows=3523087 loops=1)
Hash Cond: (up.user_magazine_id = um.id)
-> Seq Scan on user_parutions up (cost=0.00..118331.87 rows=3523087
width=158) (actual time=0.010..2334.002 rows=3523087 loops=1)
-> Hash (cost=24967.30..24967.30 rows=571230 width=98) (actual
time=1031.240..1031.240 rows=571230 loops=1)
Buckets: 1024 Batches: 128 Memory Usage: 609kB
-> Seq Scan on user_magazines um (cost=0.00..24967.30
rows=571230 width=98) (actual time=0.006..296.016 rows=571230 loops=1)
Total runtime: 58549.933 ms
(7 lignes)

Je n'arrive pas à savoir si :
* 58 secondes pour 3.5M lignes c'est correct (on trouve toujours que c'est
trop)
* Si le PLAN est correct car je suis étonné de ne pas le voir utiliser
d'index.

C'est un peu frustrant parce que je suis en train de faire des maintenance
de la base à la recherche de doublons sur des champs texte avec des
jointures un peu complexes et si cette requête "de base" n'est pas
optimale, tout le reste en pâtit.

J'ai ajusté les paramètres pour shared_mem dans postgresql.conf en suivant
les indications de différents sites, je n'ai pas constaté d'améliorations
notable des performances.

(Je songe sérieusement à mandater un audit de ce serveur et des bases qu'il
héberge... à qui je dois m'adresser ?)

Merci beaucoup, cordialement,

--
Pierre Yager