On Thu, 16 Nov 2000, Gilbert ROBERT wrote:
> La version de postgres est la 7.0 sur une Ultra 5 sous solaris 2.6.
>
> > > 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); #
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 table
> Donc cela me semble assez clair. Soit tu as un bug chez toi, soit l'index
> scan ne fonctionne pas avec des tailles grandes, soit c'est un bug de
> la 7.x, soit c'est le nom du fichier. Je viens d'essayer, si
> l'index s'appelle tartempion ça marche aussi.
entre temps, je tatonne et j'en arriv
On Thu, 16 Nov 2000, Gilbert ROBERT wrote:
> Donc la clairement j'en deduis qu'il n'utilise pas mon index!
> et pourtant j'en ai bien fait un
Allons-y: (PS: je ne connaissais pas EXPLAIN, très pratique)
test_db=> EXPLAIN SELECT * FROM sol_f WHERE id = 12345;
NOTICE: QUERY PLAN:
Seq S
>...
>
> J'avoue ne pas bien comprendre comment il détermine l'index (c'est semble-t-il
>indépendant du nom
> "Although you can use any name for the index, it is good practice to use the table
>and column names as part of the index name...") et comment le forcer à l'utiliser. Ou
>alors il y a
La version de postgres est la 7.0 sur une Ultra 5 sous solaris 2.6.
> > 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.
c'est exactement comme cela.
> Do
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 c
On Thu, 16 Nov 2000, Gilbert ROBERT wrote:
> y a t-il un moyen d'avoir les infos de temps d'une requête (statistiques) avec
>postgres?
vacuum donne certaine statistiques, et j'avais vu d'autres façons de le
faire dans la ml postgresql-user, que je n'ai pas conservées.
> Le pire c'est que grep
On Thu, 16 Nov 2000, Gilbert ROBERT wrote:
> La doc online est assez minimaliste (INDEX/CLUSTER) en ce qui concerne postgreSQL
>autrement on tombe tout
> de suite dans les docs Oracle !
Il y a un excellent bouquin référencé sur http://www.postgresql.org, qui
sera/est publié chez Addison-Wesley
At 09:50 16.11.2000 +0100, you wrote:
>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
Salut cedric,
> Quand tu dis pas unique, qu'est-ce que t'entends exactement? Tu en a
> jusqu'a combien qui on le même id? Si tu en as beaucoup, ça peu expliquer
> pour l'indexe ne marche pas. Normalement les optimiseurs ne tiennent en
> compte d'un indexe que s'il porte sur un champ déterminant e
Salut Gilbert,
On Thu, 16 Nov 2000, Gilbert ROBERT wrote:
> 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 d
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"
13 matches
Mail list logo
