Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

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

10 réponses
Avatar
Adrien A.
Salut,

J'ai remarqu=E9 un comportement =E9trange avec les requ=EAtes sur HFCS dans
WD14 (version 30f):
la m=EAme requ=EAte reprise 3 fois, l'une dans l'=E9diteur de requ=EAte, le
code SQL de la requ=EAte reprise dans l'=E9diteur de code de requ=EAte et
enfin le m=EAme code SQL dans l'=E9diteur de code de la fen=EAtre. Dans les
2 premiers cas, la requ=EAte est ex=E9cut=E9e dans le code de fen=EAtre via
HExecuteRequete, dans le 3=E8, HExecuteRequeteSQL.
Le temps d'ex=E9cution des 3 requ=EAtes est clairement diff=E9rent, =E0 la
d=E9faveur de l'=E9diteur de code de fen=EAtre !
Pour 12000 enregistrements, 5s / 6.5s / 7.5s.
J'aimerais autant que possible me passer de l'=E9diteur de requ=EAte, au
code peu souple et =E0 la flexibilit=E9 perfectible...

Avez-vous d=E9j=E0 eu affaire =E0 ce genre de comportement (HOptimise/
HOptimiseRequete semblent =EAtre d'aucune aide), m=EAme s'il peut para=EEtr=
e
logique que la requ=EAte d=E9clar=E9e dans l'=E9diteur puisse d=E9j=E0 =EAt=
re mis en
m=E9moire au moment du lancement du projet... ?

10 réponses

Avatar
Adrien A.
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.
Avatar
Firetox
Bonjour,

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

bon dev
@+

"Adrien A." a écrit dans le message de
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.
Avatar
Firetox
dasn fichier 2

desolé pour l'oubli


"Firetox" a écrit dans le message de
news:4b7576ea$0$12172$
Bonjour,

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

bon dev
@+

"Adrien A." a écrit dans le message de
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.


Avatar
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)

"Adrien A." wrote in message
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.
Avatar
Adrien A.
On 12 fév, 17:06, "free" wrote:
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 ?
Avatar
Adrien A.
On 12 fév, 16:42, "Firetox" wrote:
dasn fichier 2

desolé pour l'oubli

"Firetox" a écrit dans le message denews:4b75 76ea$0$12172$

> Bonjour,

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

> bon dev
> @+

> "Adrien A." a écrit dans le message de
>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.
Avatar
free
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." wrote in message
news:
On 12 fév, 17:06, "free" wrote:
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 ?
Avatar
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 et
suivant quels index

cordialement
Avatar
Adrien A.
On 12 fév, 18:01, "Firetox" wrote:
>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...
Avatar
Tanguy
> 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