Version imprimable
Bonjour,
J'ai deux vue dans ma base, le temps d'execution du count(*) pour une vue est excessivement long!!
1er vue
--------
SELECT * FROM mecano_view Temps d'execution 1 sec
SELECT COUNT(*) mecano_view Temps d'execution 40 sec 8O
L'Explain paln est exactement le même pour les deux query!!!
*********************************
2eme vue :
----------
SELECT * FROM piece_view Temps d'execution 300ms
SELECT COUNT(*) FROM piece_view Temps d'execution 250 ms
C'est une différence dans le choix du plan d'exécution de l'optimizeur si celui-ci est en First_rows
Quand tu fais Select * celui-ci va essayer de te retourner le plus rapidement possible le premier enregistrement et quand tu fais select count(*) celui-ci sachant qu'il doit scanner tous les enregistrements pour te donner le résultat va choisir un plan pour traiter le plus rapidement tous les enregistrements.
De plus assures-toi d'avoir tes statistiques à jours.
Rémi
désolé mais ce n'est absolument pas ça :?
SELECT * fetche les lignes (raméne la valeur de toutes les colonnes à l'écran) alors que le COUNT ne raméne qu'une valeur : le nombre de ligne.
Quand au COUNT plus long, c'est probablement dû à une HWM bien trop élevée.
dans le 2° cas, le count est plus rapide soit grace au cache soit grace à la phase de fetch moins longue :)
Ah ?Citation:
Envoyé par Fred_D
Je trouve pourtant l'hypothèse de Remi.net tout à fait pertinente, et je ne vois pas ce qui permet de la rejeter si catégoriquement.
Pourquoi, d'ailleurs, le SELECT * ne souffrirait-t-il pas d'un HWM très élevé, au même titre que le COUNT(*) ?
si je ne m'abuse le SELECT * va s'attacher à ramener les valeurs de la table alors que le COUNT(*) va compter le nombre de lignes contenues dans les blocs (me semble-t-il :oops:, je vérifierais demain avec la doc ;))... Sinon, l'hypothése du FIRST_ROWS ne tient pas (je pense ;)) parce qu'on aurait le même comportement dans les 2 requêtes (fois 40 entre SELECT et COUNT c'est quand même pas anecdotique).
Néanmoins, tu as raison, après relecture de la réponse de Remi, elle n'est pas si injustifiée que je l'ai pensé à la première lecture :ange:
PS : si on avait eu la version ça aurait été plus simple, l'optimizer FIRST_ROWS n'étant introduit que depuis la 10g :mrgreen:
Tout d'abord merci de vos réponse:) ... je verifie tout de suite mes stat.
Si non pour Fred D l'oracle que j'utilse est de l'oracle 10g Release 10.1.0.3.0 sous RedHat.
Le temps d'exécution est mesuré avec quoi ?
Parceque dans toad par exemple, il ne fetche pas toutes les lignes et il indique donc simplement le temps qui lui a falu pour ramener les 20 premières dans sa grille....
Qu'est ce qui te permet d'affirmer que le plan est exactement le même pour les 2 query ? ce qui est pas vraiment possible vu que le count génère un truc en plus...
Pour privilégier l'hypothèse de Fred_d, il faudrais savoir si c'est un table ou il y a beaucoup de delete ?
8OCitation:
Envoyé par Fred_D
pourtant je l'utilisais dés la 8i moi, j'ai du rêvé alors.... :roll: ou j'ai peut être pas compris ce que tu voulais dire... :?
au temps pour moi : http://download-uk.oracle.com/docs/c...htm#REFRN10145
décidément... j'suis vraiment pas bon sur cette discussion :mrgreen:
Tiens tu as supprimé ton message avant que je publie ma réponse, du coup j'ai supprimé aussi lachement la mienne parcque j'avais dit aussi une grosse bêtise... :mouarf:
Désolé j'ai trainé tout le monde dans l'erreur :aie: :
les Explain plan ne sont pas les mêmes!!
la mesure du temps est effectivement étais mesurer par TOAD.
J'ai mesuré le temps avec SETTIMING ON et le résultat est complètement différent.
- select count(*) 3,38 s
- select * 12,00 s
Je pense il me reste qu'a commencé l'optimisation de ma view:? chose que j'ai jamais fais :cry:
une trace s'impose pour appliquer un tkprof et trouver là où ça fait mal ;)
hé hé elle fonctionne bien ma boule de cristal hein... :mouarf:Citation:
Envoyé par z
Déja:
- la définition de la vue
- le resultat du count (ordre de grandeur),
- le plan d'exécution,
- un état des tables utilisées dans la vue: c'est à dire le nombre de lignes (à la grosse louche), et les index de ces tables.
Ce n'est pas forcément abhérant qu'un count(*) ou un select(*) prennent du temps puisqu'on demande de faire un accès complet a des tables. Selon le volume des tables, tu découvriras peut etre qu'en fait c'est déja trés performant... ;)
Que le count prenne plus de temps que le select est complètement logique par contre, puisqu'oracle se cantonne souvent à n'accéder qu'aux index quand il peut éviter de taper dans les blocs de données.