On Thu, 16 Nov 2000, Gilbert ROBERT wrote:
> Mon probl�me est le temps que prend une requ�te aussi simple que:
> select * from sol_f where id='3034';
> environ 3mn
Normal, sans index, PostgreSQL va parcourir s�quentiellement tous les
tuples, compare avec la taille de la base de donn�es concern�e et la
vitesse de ton disque.
> J'ai bien essay� de faire des index sur la colonne id p.e mais le temps
> de r�ponse est toujours aussi long!
Ainsi:
CREATE INDEX sol_f_id_idx ON sol_f(id); # ceci prend du temps.
ou alors � la d�finition de la table, en r�introduisant les donn�es ?
Je viens d'essayer avec une table sol_f avec 1 millions d'entr�es, avec
postgresql 6.5.3-23 (Debian), et ton SELECT dure environ 1/2 seconde
(valeurs al�atoires 0..32767 pour id). Apr�s avoir effac� l'index (DROP
INDEX sol_f_id_idx), cela dure plus que 20 secondes (pas 3 minutes,
d'accord).
Donc l'index semble avoir un effet, du moins pour ma configuration.
PS: les benchmarks qui montre PostgreSQL plus rapide que MySQL pour
beaucoup de tuples se basent sur les version 7.0.x de PostgreSQL.
NB: ma configuration: Pentium II 366, 128 MB de m�moire, Debian 2.2,
disque qui semble �tre capable, au moins au d�but, de faire des lectures
s�quentielles autour de 10 MByte/s d'apr�s hdparm. La db est un fichier
d'environ 60 MB, donc il peut tenir dans mon cache (en particulier s'il
contient des espaces vides).
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
