Du temps d'exécution des requêtes...

Le
Adrien A.
Salut,

J'ai remarqué un comportement étrange avec les requêtes sur HFCS dans
WD14 (version 30f):
la même requête reprise 3 fois, l'une dans l'éditeur de requête, le
code SQL de la requête reprise dans l'éditeur de code de requête et
enfin le même code SQL dans l'éditeur de code de la fenêtre. Dans les
2 premiers cas, la requête est exécutée dans le code de fenêtre via
HExecuteRequete, dans le 3è, HExecuteRequeteSQL.
Le temps d'exécution des 3 requêtes est clairement différent, à la
défaveur de l'éditeur de code de fenêtre !
Pour 12000 enregistrements, 5s / 6.5s / 7.5s.
J'aimerais autant que possible me passer de l'éditeur de requête, au
code peu souple et à la flexibilité perfectible

Avez-vous déjà eu affaire à ce genre de comportement (HOptimise/
HOptimiseRequete semblent être d'aucune aide), même s'il peut paraîtr=
e
logique que la requête déclarée dans l'éditeur puisse déjà êt=
re mis en
mémoire au moment du lancement du projet ?
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Adrien A.
Le #21183711
Ayant posté dans le désespoir et sans apporter de matériel à ma
requête, voici donc la requête en question:
SELECT
Fichier1.site,
Fichier1.instal,
Fichier1.dh_debut AS date_jour,
Fichier1.matériel AS matériel,
Fichier2.libellé
FROM
Fichier1 LEFT OUTER JOIN Fichier2 on
(Fichier1.site = Fichier2.site AND Fichier1.instal =
Fichier2.Num_instal AND Fichier1.matériel = Fichier2.matériel)
WHERE
Fichier1.site = %3
AND Fichier1.instal = %4
AND TRUNC(Fichier1.dh_debut) >= %1 AND TRUNC(Fichier1.dh_debut) < %2
ORDER BY
Fichier1.site ASC,
Fichier1.instal ASC,
Fichier1.dh_debut ASC

site, instal (entiers) et dh_debut (date/heure) sont les clefs dans
les 2 fichiers.
La même requête sur un autre fichier à la même structure que Fichie r1
est beaucoup plus rapide (il y a moins d'enregistrements cependant).

La question que je me pose est si l'indexation du fichier est
optimale, ou alors si le LEFT OUTER JOIN est pleinement interprété (en
le supprimant de la requête, j'arrive à 1.5s pour 12000 résultats sur
une table de 220000 enregistrements (Fichier2 comprend 220
enregistrements))...

Merci de vos conseils.
Firetox
Le #21183861
Bonjour,

il faut dans fichier un index sur
site,num_install, materiel

bon dev
@+

"Adrien A." news:
Ayant posté dans le désespoir et sans apporter de matériel à ma
requête, voici donc la requête en question:
SELECT
Fichier1.site,
Fichier1.instal,
Fichier1.dh_debut AS date_jour,
Fichier1.matériel AS matériel,
Fichier2.libellé
FROM
Fichier1 LEFT OUTER JOIN Fichier2 on
(Fichier1.site = Fichier2.site AND Fichier1.instal Fichier2.Num_instal AND Fichier1.matériel = Fichier2.matériel)
WHERE
Fichier1.site = %3
AND Fichier1.instal = %4
AND TRUNC(Fichier1.dh_debut) >= %1 AND TRUNC(Fichier1.dh_debut) < %2
ORDER BY
Fichier1.site ASC,
Fichier1.instal ASC,
Fichier1.dh_debut ASC

site, instal (entiers) et dh_debut (date/heure) sont les clefs dans
les 2 fichiers.
La même requête sur un autre fichier à la même structure que Fichier1
est beaucoup plus rapide (il y a moins d'enregistrements cependant).

La question que je me pose est si l'indexation du fichier est
optimale, ou alors si le LEFT OUTER JOIN est pleinement interprété (en
le supprimant de la requête, j'arrive à 1.5s pour 12000 résultats sur
une table de 220000 enregistrements (Fichier2 comprend 220
enregistrements))...

Merci de vos conseils.
Firetox
Le #21183851
dasn fichier 2

desolé pour l'oubli


"Firetox" news:4b7576ea$0$12172$
Bonjour,

il faut dans fichier un index sur
site,num_install, materiel

bon dev
@+

"Adrien A." news:
Ayant posté dans le désespoir et sans apporter de matériel à ma
requête, voici donc la requête en question:
SELECT
Fichier1.site,
Fichier1.instal,
Fichier1.dh_debut AS date_jour,
Fichier1.matériel AS matériel,
Fichier2.libellé
FROM
Fichier1 LEFT OUTER JOIN Fichier2 on
(Fichier1.site = Fichier2.site AND Fichier1.instal > Fichier2.Num_instal AND Fichier1.matériel = Fichier2.matériel)
WHERE
Fichier1.site = %3
AND Fichier1.instal = %4
AND TRUNC(Fichier1.dh_debut) >= %1 AND TRUNC(Fichier1.dh_debut) < %2
ORDER BY
Fichier1.site ASC,
Fichier1.instal ASC,
Fichier1.dh_debut ASC

site, instal (entiers) et dh_debut (date/heure) sont les clefs dans
les 2 fichiers.
La même requête sur un autre fichier à la même structure que Fichier1
est beaucoup plus rapide (il y a moins d'enregistrements cependant).

La question que je me pose est si l'indexation du fichier est
optimale, ou alors si le LEFT OUTER JOIN est pleinement interprété (en
le supprimant de la requête, j'arrive à 1.5s pour 12000 résultats sur
une table de 220000 enregistrements (Fichier2 comprend 220
enregistrements))...

Merci de vos conseils.


free
Le #21184141
juste une remarque, le test f(colonne)>xxx dans un where est une mauvaise
idée
ca empecherait d'utiliser un index éventuel
vaut mieux utiliser colonne>(f-1)(xxx)

"Adrien A." news:
Ayant posté dans le désespoir et sans apporter de matériel à ma
requête, voici donc la requête en question:
SELECT
Fichier1.site,
Fichier1.instal,
Fichier1.dh_debut AS date_jour,
Fichier1.matériel AS matériel,
Fichier2.libellé
FROM
Fichier1 LEFT OUTER JOIN Fichier2 on
(Fichier1.site = Fichier2.site AND Fichier1.instal Fichier2.Num_instal AND Fichier1.matériel = Fichier2.matériel)
WHERE
Fichier1.site = %3
AND Fichier1.instal = %4
AND TRUNC(Fichier1.dh_debut) >= %1 AND TRUNC(Fichier1.dh_debut) < %2
ORDER BY
Fichier1.site ASC,
Fichier1.instal ASC,
Fichier1.dh_debut ASC

site, instal (entiers) et dh_debut (date/heure) sont les clefs dans
les 2 fichiers.
La même requête sur un autre fichier à la même structure que Fichier1
est beaucoup plus rapide (il y a moins d'enregistrements cependant).

La question que je me pose est si l'indexation du fichier est
optimale, ou alors si le LEFT OUTER JOIN est pleinement interprété (en
le supprimant de la requête, j'arrive à 1.5s pour 12000 résultats sur
une table de 220000 enregistrements (Fichier2 comprend 220
enregistrements))...

Merci de vos conseils.
Adrien A.
Le #21184241
On 12 fév, 17:06, "free"
juste une remarque, le test f(colonne)>xxx dans un where est une mauvaise
idée
ca empecherait d'utiliser un index éventuel
vaut mieux utiliser colonne>(f-1)(xxx)



En l'occurrence comment alors faire une recherche sur une date dans
une colonne de type date/heure ?
Adrien A.
Le #21184231
On 12 fév, 16:42, "Firetox"
dasn fichier 2

desolé pour l'oubli

"Firetox"
> Bonjour,

> il faut dans fichier un index sur
> site,num_install, materiel

> bon dev
> @+

> "Adrien A." >news:
> Ayant posté dans le désespoir et sans apporter de matériel à ma
> requête, voici donc la requête en question:
> SELECT
> Fichier1.site,
> Fichier1.instal,
> Fichier1.dh_debut AS date_jour,
> Fichier1.matériel AS matériel,
> Fichier2.libellé
> FROM
> Fichier1 LEFT OUTER JOIN Fichier2 on
> (Fichier1.site = Fichier2.site AND Fichier1.instal =
> Fichier2.Num_instal AND Fichier1.matériel = Fichier2.matériel)
> WHERE
> Fichier1.site = %3
> AND Fichier1.instal = %4
> AND TRUNC(Fichier1.dh_debut) >= %1 AND TRUNC(Fichier1.dh_debut) < %2
> ORDER BY
> Fichier1.site ASC,
> Fichier1.instal ASC,
> Fichier1.dh_debut ASC

> site, instal (entiers) et dh_debut (date/heure) sont les clefs dans
> les 2 fichiers.
> La même requête sur un autre fichier à la même structure que Fi chier1
> est beaucoup plus rapide (il y a moins d'enregistrements cependant).

> La question que je me pose est si l'indexation du fichier est
> optimale, ou alors si le LEFT OUTER JOIN est pleinement interprété (en
> le supprimant de la requête, j'arrive à 1.5s pour 12000 résultats sur
> une table de 220000 enregistrements (Fichier2 comprend 220
> enregistrements))...

> Merci de vos conseils.



Pardon, j'avais oublié: site, instal et matériel sont déjà clefs de
Fichier 2, site, instal et dh_debut dans Fichier1.
free
Le #21184311
un truc genre where colonne>='date000000' ?? ou
colonne>=CreeDateHeure(date,'00:00:00')
(en remplacant CreeDateHeure par la fonction adaptée )
faut juste convertir l'argument constant en dateheure plutot que date

"Adrien A." news:
On 12 fév, 17:06, "free"
juste une remarque, le test f(colonne)>xxx dans un where est une mauvaise
idée
ca empecherait d'utiliser un index éventuel
vaut mieux utiliser colonne>(f-1)(xxx)



En l'occurrence comment alors faire une recherche sur une date dans
une colonne de type date/heure ?
Firetox
Le #21184401
>Pardon, j'avais oublié: site, instal et matériel sont déjà clefs de
Fichier 2, site, instal et dh_debut dans Fichier1.



le fait que cela soit des clés n'a rien a voir
il faut un index avec doublon dessus (dommage que explain n'existe pas en
HF) car cela permettrait de savoir comme le serveur parcours les tables et
suivant quels index

cordialement
Adrien A.
Le #21184761
On 12 fév, 18:01, "Firetox"
>Pardon, j'avais oublié: site, instal et matériel sont déjà clefs de
>Fichier 2, site, instal et dh_debut dans Fichier1.

le fait que cela soit des clés n'a rien a voir
il faut un index avec doublon dessus (dommage que explain n'existe pas en
HF) car cela permettrait de savoir comme le serveur parcours les tables e t
suivant quels index

cordialement



Je ne suis pas sûr d'avoir bien compris de quoi il retournait... Dans
ce fichier, j'ai créé une clef composée avec les 3 clefs en question,
la requête est maintenant plus longue d'une seconde pleine...
Tanguy
Le #21186141
> Je ne suis pas sûr d'avoir bien compris de quoi il retournait... Dans
ce fichier, j'ai créé une clef composée avec les 3 clefs en question,
la requête est maintenant plus longue d'une seconde pleine...



Les clés composées sont utilisées généralement pour créer une clé
unique sur plusieurs colonnes... a mon avis ca n'est pas réellement
utilisé pour les jointures SQL sauf si le nom de la colonne composée en
question est utilisée comme jointure...

Il faut mettre les colonnes en clé séparément...

Je mettrais site en dernier dans la liste des conditions car c'est
celui
qui a le plus de résultats... le moins déterminant donc... Mais ca je
ne
sais pas bien comment c'est géré en Hyperfile SQL

--
Contact : http://tanguy.ath.cx
Publicité
Poster une réponse
Anonyme