Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
WebShaker
Le 14/07/2010 23:40, WebShaker a écrit :
alors ma question est qu'est ce que c'est que cette index test_pkey si ce n'est pas exactement la meme chose que mon index test_idtest ???
Bon ben y a pas de doute c'est bien la même chose. j'ai viré mon index pour faire des tests... C'est redevenu lent Je l'ai remis puis retiré à nouveau.
Et byzarrement, a présent il utilise l'index d'origine... étrange. peut etre que l'auto-vaacum est passé par là...
Désolé pour le coup de panique ;) Je me voyais deja diviser par 10 le temps de traitement de mes requetes :)
Etienne
Le 14/07/2010 23:40, WebShaker a écrit :
alors ma question est qu'est ce que c'est que cette index test_pkey si
ce n'est pas exactement la meme chose que mon index test_idtest ???
Bon ben y a pas de doute c'est bien la même chose.
j'ai viré mon index pour faire des tests...
C'est redevenu lent
Je l'ai remis puis retiré à nouveau.
Et byzarrement, a présent il utilise l'index d'origine... étrange.
peut etre que l'auto-vaacum est passé par là...
Désolé pour le coup de panique ;)
Je me voyais deja diviser par 10 le temps de traitement de mes requetes :)
alors ma question est qu'est ce que c'est que cette index test_pkey si ce n'est pas exactement la meme chose que mon index test_idtest ???
Bon ben y a pas de doute c'est bien la même chose. j'ai viré mon index pour faire des tests... C'est redevenu lent Je l'ai remis puis retiré à nouveau.
Et byzarrement, a présent il utilise l'index d'origine... étrange. peut etre que l'auto-vaacum est passé par là...
Désolé pour le coup de panique ;) Je me voyais deja diviser par 10 le temps de traitement de mes requetes :)
Etienne
Patrick Mevzek
Le Wed, 14 Jul 2010 23:40:55 +0200, WebShaker a écrit:
j'ai une table CREATE TABLE test ( idtest serial, autre_champ, PRIMARY key (idtag) );
lorsque je fais un di Schema | Name | Type | Owner | Table ------------------------------------------- public | test_pkey | index | moi | test
jusque la tout va bien en je me dis que j'ai un index sur ma table (et je suppose qu'il est sur la cle)
serial équivaut à création d'une séquence + usage de NOT NULL et nextval('le nom de la sequence')
Je cite la documentation: (In most cases you would also want to attach a UNIQUE or PRIMARY KEY constraint to prevent duplicate values from being inserted by accident, but this is not automatic.)
PRIMARY KEY est l'équivalent de UNIQUE + NOT NULL (cf documentation) et UNIQUE.
Et pour des raisons de performance, PostgreSQL créé un index pour chaque contrainte UNIQUE.
Donc en résumé, oui vous avez un index sur test.idtag (j'imagine qu'il y a une erreur de copier coller, votre clef s'appelle idtest puis idtag dans la contrainte) et c'est ce que le di montre :-)
Sauf que voila mon exlain analyze me dit (lors d'un jointure) qu'il n'utilse pas d'index.
L'usage d'un index n'est pas *automatique*, même s'il existe. Cela dépend - de la taille des tables - de quand remonte le dernier ANALYZE (et donc si les statistiques sont fiables ou non), ou le autovacuum qui fait un ANALYZE - de la répartition statistique des valeurs - du type des valeurs - du type de jointure et de tout un tas d'autres options.
Donc ce n'est pas parce qu'un index existe qu'il sera nécessairement toujours utilisé.
Bonne pratique: après chaque modification substantielle du contenu des tables (pas de leur schéma), faire un ANALYZE sur les tables concernées. En tout cas avant tout EXPLAIN :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
Le Wed, 14 Jul 2010 23:40:55 +0200, WebShaker a écrit:
j'ai une table
CREATE TABLE test (
idtest serial,
autre_champ,
PRIMARY key (idtag)
);
lorsque je fais un di
Schema | Name | Type | Owner | Table
------------------------------------------- public | test_pkey | index |
moi | test
jusque la tout va bien en je me dis que j'ai un index sur ma table (et
je suppose qu'il est sur la cle)
serial équivaut à création d'une séquence + usage de NOT NULL
et nextval('le nom de la sequence')
Je cite la documentation:
(In most cases you would also want to attach a UNIQUE or PRIMARY KEY
constraint to prevent duplicate values from being inserted by accident,
but this is not automatic.)
PRIMARY KEY est l'équivalent de UNIQUE + NOT NULL (cf documentation)
et UNIQUE.
Et pour des raisons de performance, PostgreSQL créé un index pour chaque
contrainte UNIQUE.
Donc en résumé, oui vous avez un index sur test.idtag
(j'imagine qu'il y a une erreur de copier coller, votre clef s'appelle
idtest puis idtag dans la contrainte) et c'est ce que le di montre :-)
Sauf que voila mon exlain analyze me dit (lors d'un jointure) qu'il
n'utilse pas d'index.
L'usage d'un index n'est pas *automatique*, même s'il existe.
Cela dépend
- de la taille des tables
- de quand remonte le dernier ANALYZE (et donc si les statistiques sont
fiables ou non), ou le autovacuum qui fait un ANALYZE
- de la répartition statistique des valeurs
- du type des valeurs
- du type de jointure
et de tout un tas d'autres options.
Donc ce n'est pas parce qu'un index existe qu'il sera nécessairement
toujours utilisé.
Bonne pratique: après chaque modification substantielle du contenu des
tables (pas de leur schéma), faire un ANALYZE sur les tables concernées.
En tout cas avant tout EXPLAIN :-)
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>
Le Wed, 14 Jul 2010 23:40:55 +0200, WebShaker a écrit:
j'ai une table CREATE TABLE test ( idtest serial, autre_champ, PRIMARY key (idtag) );
lorsque je fais un di Schema | Name | Type | Owner | Table ------------------------------------------- public | test_pkey | index | moi | test
jusque la tout va bien en je me dis que j'ai un index sur ma table (et je suppose qu'il est sur la cle)
serial équivaut à création d'une séquence + usage de NOT NULL et nextval('le nom de la sequence')
Je cite la documentation: (In most cases you would also want to attach a UNIQUE or PRIMARY KEY constraint to prevent duplicate values from being inserted by accident, but this is not automatic.)
PRIMARY KEY est l'équivalent de UNIQUE + NOT NULL (cf documentation) et UNIQUE.
Et pour des raisons de performance, PostgreSQL créé un index pour chaque contrainte UNIQUE.
Donc en résumé, oui vous avez un index sur test.idtag (j'imagine qu'il y a une erreur de copier coller, votre clef s'appelle idtest puis idtag dans la contrainte) et c'est ce que le di montre :-)
Sauf que voila mon exlain analyze me dit (lors d'un jointure) qu'il n'utilse pas d'index.
L'usage d'un index n'est pas *automatique*, même s'il existe. Cela dépend - de la taille des tables - de quand remonte le dernier ANALYZE (et donc si les statistiques sont fiables ou non), ou le autovacuum qui fait un ANALYZE - de la répartition statistique des valeurs - du type des valeurs - du type de jointure et de tout un tas d'autres options.
Donc ce n'est pas parce qu'un index existe qu'il sera nécessairement toujours utilisé.
Bonne pratique: après chaque modification substantielle du contenu des tables (pas de leur schéma), faire un ANALYZE sur les tables concernées. En tout cas avant tout EXPLAIN :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
