Problème de performance : une idée ?

Pareillement, c'est une fonctionnalité que j'aimerai bien voir débarquer chez Oracle.

@Rei Ichido
Je ne doute pas que ça devrait être assez intéressant mais pour l'instant je ne vois pas très bien les avantages. Donc quelques explications de plus pour y vois clairement de quoi il s’agit seraient bien venues.

Citation:

---

Envoyé par mnitu

@Rei Ichido
Je ne doute pas que ça devrait être assez intéressant mais pour l'instant je ne vois pas très bien les avantages. Donc quelques explications de plus pour y vois clairement de quoi il s’agit seraient bien venues.

---

Typiquement, il y a des cas où pour éviter les accès à la table par ROWID après utilisation de l'index (pour récupérer des valeurs qui seront utilisés dans le SELECT), on rajoute des colonnes dans l'index. Ce n'est pas très joli et induit le SGBD en erreur (on rajoute de la profondeur inutile). L'option INCLUDE permet exactement cela.
Concrètement, cela permet d'avoir les effets positifs d'une IOT mais pour une partie de la table.

Soit par exemple une requête du genre :

Code:

---

1 2 3 4 5

SELECT sum(montant) AS Somme FROM maGrosseTable WHERE typeFacture = ? AND dateComptable >= getdate() - 1

---

Concrètement, ce qui va m'intéresser dans mon index (pour déterminer les lignes intéressantes), c'est (TypeFacture,DateComptable). Cependant si ma table est imposante, je vais me retrouver à faire un accès à la table pour tous les ROWID, et concrètement c'est ça qui risque de me consommer le plus de temps dans l'exécution de ma requête.
Sur Oracle, je peux feinter en faisant un index (TypeFacture,DateComptable,Montant), mais ça devient problématique à cause du scan qu'impose la condition sur DateComptable.
Sur SQL Server, je peux faire un index (TypeFacture,DateComptable) INCLUDE (Montant) qui permet simplement de stocker au niveau feuille, en plus des ROWID, la valeur de la colonne Montant. Ici ça m'éviterait tout accès à la table.
Bien sûr, ce n'est pas gratuit en terme de maintenance de l'index, mais ça reste fort pratique :)

Bonour,

Citation:

---

Envoyé par Rei Ichido

Sur SQL Server, je peux faire un index (TypeFacture,DateComptable) INCLUDE (Montant) qui permet simplement de stocker au niveau feuille, en plus des ROWID, la valeur de la colonne Montant.

---

C'est quasiment la même chose lorsqu'on rajoute la colonne Montant à l'index sous Oracle. Il ne s'agit pas de 'feinter': c'est une plan d'exécution tout à fait pertinent pour Oracle. INCLUDE permet simplement de ne pas trier les entrées d'index sur cette colonne. Et la différence avec le INCLUDE est minime et ne se verra pas sur la requête en question, mais éventuellement sur d'autres requêtes qui doivent aller voir la table, car l'ajout de la colonne peut changer le clustering_factor.

Cordialement,
Franck.

@Rei Ichido
Merci pour vos explications détaillés qui mont permis de mieux comprendre de quoi il s’agit.
Je pense qu’en fait vous avez exactement la même fonctionnalité avec une table IOT qu’utilise l’overflow segment (avec la fameuse clause INCLUDE en plus :lol:). Le besoin de mettre ça en œuvre pour une table normale (heap table) est au moins discutable.

L'IOT impose quand même d'avoir une clef primaire, l'index include n'a pas cette contrainte.

Au lieu d'indexer deux colonnes, on en index une et on met la et les valeurs de l'autres dans les feuilles.

J'ai lancé rapidement quelques comparatifs sur SQL-Server, en terme de place utilisée l'écart était trop faible pour être significatif, par contre j'ai pu observer jusqu'à un facteur deux sur le temps de création de l'index include vs l'index deux colonnes.

Ca devrait s’expliquer facilement par le besoin de trier sur la deuxième colonne dans le cas d’un index sur deux colonnes par rapport à l’index couvrant sur une colonne (il n’y pas des tris sur la deuxième dans ce cas). Mais encore dans son utilisation ça reste quelque chose de marginal. Les index ne sont pas conçus pour intégrer tous les colonnes d’une table. Si c’est le cas c’est l’IOT. Une requête de genre présenté par Rai Ichido peut bénéficier des autres types de d’optimisation. Bref, c’est sympa mais rien de révolutionnaire.

Citation:

---

Envoyé par mnitu

Les index ne sont pas conçus pour intégrer tous les colonnes d’une table. Si c’est le cas c’est l’IOT. Une requête de genre présenté par Rai Ichido peut bénéficier des autres types de d’optimisation. Bref, c’est sympa mais rien de révolutionnaire.

---

Personnellement, je m'en sers surtout sur des tables obèses présentes dans des ERP (quand je dis obèse, c'est mode sumo : une centaine de colonnes, avec bien sur des varchar à foison).
Vous me direz, "mauvais modèle". On est bien d'accord, sauf que bien sûr on ne peut pas le changer ... Du coup les index avec INCLUDE sont vraiment pratiques. Et puis une table ne peut être IOT que selon UNE clé primaire ; or je pourrais vouloir faire une requête similaire à celle que j'ai proposée, mais par exemple en groupant par fournisseur.

Rien de révolutionnaire => encore une fois, je suis d'accord, ça reste du domaine du pratique, pas de l'indispensable.

Citation:

---

Envoyé par Rei Ichido

...Rien de révolutionnaire => encore une fois, je suis d'accord, ça reste du domaine du pratique, pas de l'indispensable.

---

Oui des choses de ce type répondent à des cas réels d’utilisation et peuvent être assez utiles dans certains contextes spécifiques.
Bon après réflexion mon approchement avec IOT avec overflow segment ne tiens pas la route parce que la partie include est stockée ailleurs et non pas dans l’index. Or dans ce cas les colonnes include doivent être stockées dans l’index. Le plus proche chez Oracle reste donc l’ajout de la colonne dans l’index avec les désavantages qu’elle a.