J'ai donc crée l'index suivant
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
et pour sélectionner les produits du catalogue 1 je fais
SELECT * FROM product WHERE (actif_bitfield & 1) = 1;
Et là, semblerai que mon index ne servent à rien...
pourquoi ??? Ai je fais une erreur ou postgreSQL a juste décide de ne
pas utiliser mon index ?
J'ai donc crée l'index suivant
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
et pour sélectionner les produits du catalogue 1 je fais
SELECT * FROM product WHERE (actif_bitfield & 1) = 1;
Et là, semblerai que mon index ne servent à rien...
pourquoi ??? Ai je fais une erreur ou postgreSQL a juste décide de ne
pas utiliser mon index ?
J'ai donc crée l'index suivant
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
et pour sélectionner les produits du catalogue 1 je fais
SELECT * FROM product WHERE (actif_bitfield & 1) = 1;
Et là, semblerai que mon index ne servent à rien...
pourquoi ??? Ai je fais une erreur ou postgreSQL a juste décide de ne
pas utiliser mon index ?
On 20/09/2010 12:26, Etienne wrote:
Salut,
Ok pour l'index, mais il faut voir l'explain analyse de la requete pour
en dire plus. Il est par exemple possible qu'il décide de ne pas
utiliser l'index parce qu'il y a trop peu de donnée dans la table.
On 20/09/2010 12:26, Etienne wrote:
Salut,
Ok pour l'index, mais il faut voir l'explain analyse de la requete pour
en dire plus. Il est par exemple possible qu'il décide de ne pas
utiliser l'index parce qu'il y a trop peu de donnée dans la table.
On 20/09/2010 12:26, Etienne wrote:
Salut,
Ok pour l'index, mais il faut voir l'explain analyse de la requete pour
en dire plus. Il est par exemple possible qu'il décide de ne pas
utiliser l'index parce qu'il y a trop peu de donnée dans la table.
ma table produit hérite d'une autre table (celle qui contient
actif_bitfield)
si je crée l'index sur la table parent il n'est pas utilisé et si je le
crée sur la table produit directement il l'est.
C'est donc sans doute un choix de postgres. car je ne vois pas ce qui
l'empècherai d'utiliser l'index créé sur la table parent.
Par contre la grosse question qui reste en suspend c'est est il possible
de regrouper les indexes.
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
CREATE idx_catalogue2 ON product ((actif_bitfield & 2));
CREATE idx_catalogue3 ON product ((actif_bitfield & 4));
CREATE idx_catalogue4 ON product ((actif_bitfield & 8));
en un seul ?
Comment peut on savoir la taille (sur disque et mémoire) prise par les
tables et par les indexes.
ma table produit hérite d'une autre table (celle qui contient
actif_bitfield)
si je crée l'index sur la table parent il n'est pas utilisé et si je le
crée sur la table produit directement il l'est.
C'est donc sans doute un choix de postgres. car je ne vois pas ce qui
l'empècherai d'utiliser l'index créé sur la table parent.
Par contre la grosse question qui reste en suspend c'est est il possible
de regrouper les indexes.
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
CREATE idx_catalogue2 ON product ((actif_bitfield & 2));
CREATE idx_catalogue3 ON product ((actif_bitfield & 4));
CREATE idx_catalogue4 ON product ((actif_bitfield & 8));
en un seul ?
Comment peut on savoir la taille (sur disque et mémoire) prise par les
tables et par les indexes.
ma table produit hérite d'une autre table (celle qui contient
actif_bitfield)
si je crée l'index sur la table parent il n'est pas utilisé et si je le
crée sur la table produit directement il l'est.
C'est donc sans doute un choix de postgres. car je ne vois pas ce qui
l'empècherai d'utiliser l'index créé sur la table parent.
Par contre la grosse question qui reste en suspend c'est est il possible
de regrouper les indexes.
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
CREATE idx_catalogue2 ON product ((actif_bitfield & 2));
CREATE idx_catalogue3 ON product ((actif_bitfield & 4));
CREATE idx_catalogue4 ON product ((actif_bitfield & 8));
en un seul ?
Comment peut on savoir la taille (sur disque et mémoire) prise par les
tables et par les indexes.
par exemple un produit est t-il actif pour un catalogue précis.
ma table est du genre
CREATE TABLE product (
"idproduct" serial,
...
"actif_bitfield" integer,
PRIMARY KEY (idproduct)
);
J'ai donc crée l'index suivant
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
et pour sélectionner les produits du catalogue 1 je fais SELECT * FROM
product WHERE (actif_bitfield & 1) = 1;
Et là, semblerai que mon index ne servent à rien... pourquoi ??? Ai je
fais une erreur ou postgreSQL a juste décide de ne pas utiliser mon
index ?
PS: y a que moi qui ai des questions à poser sur les SGBDs ??? :)
par exemple un produit est t-il actif pour un catalogue précis.
ma table est du genre
CREATE TABLE product (
"idproduct" serial,
...
"actif_bitfield" integer,
PRIMARY KEY (idproduct)
);
J'ai donc crée l'index suivant
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
et pour sélectionner les produits du catalogue 1 je fais SELECT * FROM
product WHERE (actif_bitfield & 1) = 1;
Et là, semblerai que mon index ne servent à rien... pourquoi ??? Ai je
fais une erreur ou postgreSQL a juste décide de ne pas utiliser mon
index ?
PS: y a que moi qui ai des questions à poser sur les SGBDs ??? :)
par exemple un produit est t-il actif pour un catalogue précis.
ma table est du genre
CREATE TABLE product (
"idproduct" serial,
...
"actif_bitfield" integer,
PRIMARY KEY (idproduct)
);
J'ai donc crée l'index suivant
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
et pour sélectionner les produits du catalogue 1 je fais SELECT * FROM
product WHERE (actif_bitfield & 1) = 1;
Et là, semblerai que mon index ne servent à rien... pourquoi ??? Ai je
fais une erreur ou postgreSQL a juste décide de ne pas utiliser mon
index ?
PS: y a que moi qui ai des questions à poser sur les SGBDs ??? :)
si je crée l'index sur la table parent il n'est pas utilisé et si je le
crée sur la table produit directement il l'est. C'est donc sans doute un
choix de postgres. car je ne vois pas ce qui l'empècherai d'utiliser
l'index créé sur la table parent.
Par contre la grosse question qui reste en suspend c'est est il possible
de regrouper les indexes.
si je crée l'index sur la table parent il n'est pas utilisé et si je le
crée sur la table produit directement il l'est. C'est donc sans doute un
choix de postgres. car je ne vois pas ce qui l'empècherai d'utiliser
l'index créé sur la table parent.
Par contre la grosse question qui reste en suspend c'est est il possible
de regrouper les indexes.
si je crée l'index sur la table parent il n'est pas utilisé et si je le
crée sur la table produit directement il l'est. C'est donc sans doute un
choix de postgres. car je ne vois pas ce qui l'empècherai d'utiliser
l'index créé sur la table parent.
Par contre la grosse question qui reste en suspend c'est est il possible
de regrouper les indexes.
Salut.
Je me rebiffe avec mon idée de champ de bit.
Salut.
Je me rebiffe avec mon idée de champ de bit.
Salut.
Je me rebiffe avec mon idée de champ de bit.
Salut.
Je me rebiffe avec mon idée de champ de bit.
en fait j'ai des bits qui active une donnée en fonction du bit allumé.
par exemple un produit est t-il actif pour un catalogue précis.
ma table est du genre
CREATE TABLE product (
"idproduct" serial,
...
"actif_bitfield" integer,
PRIMARY KEY (idproduct)
);
Supponsons que le bit 1 concerne le catalogue 1
le 2 le catalogue 2, ...
REM: Ok je suis limité a 32 catalogue, mais c'est un detail vu que j'en
ai que 4.
J'ai donc crée l'index suivant
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
et pour sélectionner les produits du catalogue 1 je fais
SELECT * FROM product WHERE (actif_bitfield & 1) = 1;
Et là, semblerai que mon index ne servent à rien...
pourquoi ??? Ai je fais une erreur ou postgreSQL a juste décide de ne
pas utiliser mon index ?
Etienne
PS: dans la foulé, y a t-il un index unique que je puisse créer pour
remplacer mes 4 indexes:
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
CREATE idx_catalogue2 ON product ((actif_bitfield & 2));
CREATE idx_catalogue3 ON product ((actif_bitfield & 4));
CREATE idx_catalogue4 ON product ((actif_bitfield & 8));
Merci
Etienne
PS: y a que moi qui ai des questions à poser sur les SGBDs ??? :)
Salut.
Je me rebiffe avec mon idée de champ de bit.
en fait j'ai des bits qui active une donnée en fonction du bit allumé.
par exemple un produit est t-il actif pour un catalogue précis.
ma table est du genre
CREATE TABLE product (
"idproduct" serial,
...
"actif_bitfield" integer,
PRIMARY KEY (idproduct)
);
Supponsons que le bit 1 concerne le catalogue 1
le 2 le catalogue 2, ...
REM: Ok je suis limité a 32 catalogue, mais c'est un detail vu que j'en
ai que 4.
J'ai donc crée l'index suivant
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
et pour sélectionner les produits du catalogue 1 je fais
SELECT * FROM product WHERE (actif_bitfield & 1) = 1;
Et là, semblerai que mon index ne servent à rien...
pourquoi ??? Ai je fais une erreur ou postgreSQL a juste décide de ne
pas utiliser mon index ?
Etienne
PS: dans la foulé, y a t-il un index unique que je puisse créer pour
remplacer mes 4 indexes:
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
CREATE idx_catalogue2 ON product ((actif_bitfield & 2));
CREATE idx_catalogue3 ON product ((actif_bitfield & 4));
CREATE idx_catalogue4 ON product ((actif_bitfield & 8));
Merci
Etienne
PS: y a que moi qui ai des questions à poser sur les SGBDs ??? :)
Salut.
Je me rebiffe avec mon idée de champ de bit.
en fait j'ai des bits qui active une donnée en fonction du bit allumé.
par exemple un produit est t-il actif pour un catalogue précis.
ma table est du genre
CREATE TABLE product (
"idproduct" serial,
...
"actif_bitfield" integer,
PRIMARY KEY (idproduct)
);
Supponsons que le bit 1 concerne le catalogue 1
le 2 le catalogue 2, ...
REM: Ok je suis limité a 32 catalogue, mais c'est un detail vu que j'en
ai que 4.
J'ai donc crée l'index suivant
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
et pour sélectionner les produits du catalogue 1 je fais
SELECT * FROM product WHERE (actif_bitfield & 1) = 1;
Et là, semblerai que mon index ne servent à rien...
pourquoi ??? Ai je fais une erreur ou postgreSQL a juste décide de ne
pas utiliser mon index ?
Etienne
PS: dans la foulé, y a t-il un index unique que je puisse créer pour
remplacer mes 4 indexes:
CREATE idx_catalogue1 ON product ((actif_bitfield & 1));
CREATE idx_catalogue2 ON product ((actif_bitfield & 2));
CREATE idx_catalogue3 ON product ((actif_bitfield & 4));
CREATE idx_catalogue4 ON product ((actif_bitfield & 8));
Merci
Etienne
PS: y a que moi qui ai des questions à poser sur les SGBDs ??? :)
1) un WHERE contenant une fonction ne peut pas utiliser un index car
le prédicat de jointure n'est pas "sargeable".
1) un WHERE contenant une fonction ne peut pas utiliser un index car
le prédicat de jointure n'est pas "sargeable".
1) un WHERE contenant une fonction ne peut pas utiliser un index car
le prédicat de jointure n'est pas "sargeable".
Le 20/09/2010 12:26, Etienne a écrit :
1) un WHERE contenant une fonction ne peut pas utiliser un index car le
prédicat de jointure n'est pas "sargeable".
Vous avez créé un index calculé, c'est bien... mais
2) la distribution (ou son inverse, la sélectivité) des données dans une
colonne ou une expression n'ayant que 2 valeurs (0 ou 1) est faible et
donc l'utilisation d'un index quasi nul, sauf si ladite distribution est
très déséquilibrée en faveur de l'une des deux valeurs et uniquement
pour un filtre appliqué à la valeur la plus faible (moins de 30% dans
tous les cas si l'index est couvrant, mais plutôt 10% en général).
Lisez les articles que j'ai écrit à ce sujet. En particulier :
http://sqlpro.developpez.com/cours/quoi-indexer/
http://sqlpro.developpez.com/optimisation/indexation/ComparaisonRequetesIndexation2.pdf
Le 20/09/2010 12:26, Etienne a écrit :
1) un WHERE contenant une fonction ne peut pas utiliser un index car le
prédicat de jointure n'est pas "sargeable".
Vous avez créé un index calculé, c'est bien... mais
2) la distribution (ou son inverse, la sélectivité) des données dans une
colonne ou une expression n'ayant que 2 valeurs (0 ou 1) est faible et
donc l'utilisation d'un index quasi nul, sauf si ladite distribution est
très déséquilibrée en faveur de l'une des deux valeurs et uniquement
pour un filtre appliqué à la valeur la plus faible (moins de 30% dans
tous les cas si l'index est couvrant, mais plutôt 10% en général).
Lisez les articles que j'ai écrit à ce sujet. En particulier :
http://sqlpro.developpez.com/cours/quoi-indexer/
http://sqlpro.developpez.com/optimisation/indexation/ComparaisonRequetesIndexation2.pdf
Le 20/09/2010 12:26, Etienne a écrit :
1) un WHERE contenant une fonction ne peut pas utiliser un index car le
prédicat de jointure n'est pas "sargeable".
Vous avez créé un index calculé, c'est bien... mais
2) la distribution (ou son inverse, la sélectivité) des données dans une
colonne ou une expression n'ayant que 2 valeurs (0 ou 1) est faible et
donc l'utilisation d'un index quasi nul, sauf si ladite distribution est
très déséquilibrée en faveur de l'une des deux valeurs et uniquement
pour un filtre appliqué à la valeur la plus faible (moins de 30% dans
tous les cas si l'index est couvrant, mais plutôt 10% en général).
Lisez les articles que j'ai écrit à ce sujet. En particulier :
http://sqlpro.developpez.com/cours/quoi-indexer/
http://sqlpro.developpez.com/optimisation/indexation/ComparaisonRequetesIndexation2.pdf
Le 25/09/10 11:33, SQLpro a écrit :1) un WHERE contenant une fonction ne peut pas utiliser un index car
le prédicat de jointure n'est pas "sargeable".
Dans le cas de PostgreSQL, à partir du moment ou une fonction est
marquée comme étant immutable, elle peut parfaitement être indexée.
Et PostgreSQL ne se privera pas d'utiliser cet index s'il juge utile de
l'utiliser.
Une fonction immutable est une fonction dont le résultat ne dépend
strictement que de ses arguments et en aucun cas de valeurs provenant
d'autres tables ou basée selon l'heure.
cf. <http://www.postgresql.org/docs/9/static/sql-crea/functteindex.html>
HTH,
Le 25/09/10 11:33, SQLpro a écrit :
1) un WHERE contenant une fonction ne peut pas utiliser un index car
le prédicat de jointure n'est pas "sargeable".
Dans le cas de PostgreSQL, à partir du moment ou une fonction est
marquée comme étant immutable, elle peut parfaitement être indexée.
Et PostgreSQL ne se privera pas d'utiliser cet index s'il juge utile de
l'utiliser.
Une fonction immutable est une fonction dont le résultat ne dépend
strictement que de ses arguments et en aucun cas de valeurs provenant
d'autres tables ou basée selon l'heure.
cf. <http://www.postgresql.org/docs/9/static/sql-crea/functteindex.html>
HTH,
Le 25/09/10 11:33, SQLpro a écrit :1) un WHERE contenant une fonction ne peut pas utiliser un index car
le prédicat de jointure n'est pas "sargeable".
Dans le cas de PostgreSQL, à partir du moment ou une fonction est
marquée comme étant immutable, elle peut parfaitement être indexée.
Et PostgreSQL ne se privera pas d'utiliser cet index s'il juge utile de
l'utiliser.
Une fonction immutable est une fonction dont le résultat ne dépend
strictement que de ses arguments et en aucun cas de valeurs provenant
d'autres tables ou basée selon l'heure.
cf. <http://www.postgresql.org/docs/9/static/sql-crea/functteindex.html>
HTH,