Le Jeudi, 16 Novembre 2000 09.50, vous avez �crit :
> Bonjour,
Bonjour !
>
> C'est un peu hors sujet et veuillez m'en excuser MAIS j'en un truc sur le
> feu (pour �tre poli) et je ne suis pas un expert des grandes BD. Mes
> diverses tentatives se sont sold�es par des �checs.
>
> Voila j'ai 3 tables de plus de 3M d'entr�es sol_f, sol_i, sol_d
>
> Table "sol_f"
> Attribute | Type | Modifier
> -----------+----------+----------
> id | integer |
> ref | text |
> sentpos | smallint |
> wordpos | text |
Je pense que dans ton cas, ce sont les champs texts qui g�nent. Je n'ai pas
regard� comment �tait trait�s ces champs par postgres, mais ils ralentissent
une bonne partie des moteurs de DB avec lesquels j'ai travaill�. Regarde si
tu ne peux pas les remplacer par des char(xx) (pour la colonne ref ?) ou, si
tu ne les utilises pas beaucoup, essaye de les d�placer dans une autre table
en gardant juste une r�f�rence dans cette table. (Je doute que cela soit ton
cas... mais bon).
> Mon probl�me est le temps que prend une requ�te aussi simple que:
> select * from sol_f where id='3034';
> environ 3mn
Le * n'est pas optimal, mais cela ne change pas grand chose je pense, essaye
de le remplacer par les colonnes dont tu as besoin... Et comme Marc l'a d�j�
dit : select id, ref, sentpos from sol_f where id=3034; <-- sans les quotes.
Pissinon, ben je pense que de creuser dans la voie de l'index qui semble ne
pas marcher, c'est la meilleure fa�on d'am�liorer la situation. (J'ai
travaill� sur une base qu'on m'avait refil� sans index... Avec des indexes,
la performance s'est vue mutlipli� par un facteur 20 !)
Bonne chance !
Florian
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
