Requête lente sur une grosse table

[mr_keyser]

Bonjour,

J'ai une table "utilisateurs" avec des champs classiques (nom, prénom, age, ...).
J'ai 350 000 utilisateurs.
J'ai un champ boolean qui me sert pour des traitements divers...
Je fais une requête, tout simple, qui prend un temps fou!!
UPDATE utilisateurs SET bprocessed = 'False'
Je met entre 5 et 10 minutes pour executer ça, parfois plus...

J'ai essayé comme ça :
UPDATE utilisateurs SET bprocessed = 'False' WHERE bprocessed = 'True'
Je gagne un peu, mais c'est encore très long...

Auriez-vous des idées pour que je speed un peu plus de genre de requête?
J'ai essayé de passer par une function, mais c'est pire.
Je connais pas trop les transactions, peut etre par là il y aurai une piste...

Merci de votre aide et de vos conseils.

Mathieu

[hpalpha]

Bonjour,


350 000 enregistrements ce n'est pas monstrueux, donc il ya peut etre un peu d'optimisation a faire.

quand tu fais un update, tu n'utilise pas de clef ?
parce faire a chaque fois un update de la table sans critere, pg comme tout autre sgbd fait du scan table (il parcours chaque enregistrement)

Il faut passer par un index, mais mettre un index sur bprocessed n'est pas non plus jusdicieux, un index est efficace quand il y a beacoup de données differentes, or true / false, ca le fait pas.

en fait, il faut peut etre repenser la maniere d'attaquer ta base, a quoi te sert bprocessed ?

[mr_keyser]

L'idée, c'est que tous ces utilisateurs arrivent d'une autre application, où je n'ai pas la main.
J'ai un fichier csv avec tous mes utilisateurs qui arrivent.
J'import ce fichier. Je l'import pas brute, je fais des traitements, vérification de données (le fichier est souvent pourri), calcul de certains champs, et j'update si l'utilisateur existe ou j'insert.
Tous les utilisateurs présent dans la base mais NON présent dans le fichier doivent être supprimé.
Donc j'utilise ce boolean "bprocessed". Je le met à False au début de l'import pour tous les utilisateurs, puis j'insert, et update en mettant ce boolean à True.
A la fin de l'import, tous les utilisateurs avec un "bprocessed" = 'False', je les supprime.
L'import suivant, je repasse bprocessed à False pour tout le monde, c'est ça qui me prend du temps...
La méthode n'est peut etre pas terrible (ce système de boolean), mais j'ai pas trouvé mieux.
Si vous avez des idées, je suis preneur.

Merci

Mathieu

[hpalpha]

Peux tu me donner une description de ton serveur (RAM/PROC/ DD / RAID ) ?
on va essayer d'optimiser si ce n'est pas deja fait.

[mr_keyser]

Merci de ton aide!

Alors le serveur:
Proc: Intel Xeon 2,50GHz
Ram: 1,50 Go
OS: Windows Server 2003
Prostgres: 8.1.3

L'installation est basique, aucune optimisation ou configuration n'a été faite.

Merci.

mathieu

[hpalpha]

En terme de perf, sous windows, je sais pas ce que ca va donner, mais on va essayer :


essaye les valeurs suivantes dans postgresql.conf

max_connections = xx
>> combien d'users se connecte sur la base ? du peut peut etre reduire

shared_buffers = 64MB
work_mem = 8MB
maintenance_work_mem = 32MB
max_fsm_pages = 409600 # par defaut 204800



Redemarre le service, peut etre que ca repartira pas, pas de panic, reduit les val (surtout max_fsm_pages), le parametrage depend des machines, et sous windows ca tourne pas pareil pour la gestion de la memoire

[MrX]

Le problème peut également venir d'un trigger.

@++ Xav

[bustaf]

Bonsoir
Cela semble long
Vous pouvez essayer de créer un index.
1] CREATE INDEX utilisateurs.idx ON utilisateurs USING BTREE(bprocessed);
2] CLUSTER utilisateurs.idx ON utilisateurs ;
Lancez aussi au shell vacuum verbose analyze;
faites un nouveau test de façon identique...
Pour infos les performances de Postgresql (8.2) sur O/S Microsoft (Longhorn / server 2008) sont pratiquement
identiques comparativement aux autres versions qui tournent sur LINUX ,BSD ,AIX OU SOLARIS etc..
Pour la forme je pense qu'une requête sur deux tables ensuite permutées peut être plus efficace (en temps de reponse).
Bonne chance