Problème de performance avec les dates sous Oracle

La norme SQL évolue : tirez le meilleur d'un SGBD qui la respecte en écrivant du SQL moderne avec en complément PL/pgSQL, php, java etc.
Répondre
Phil
Administrateur du site
Messages : 258
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Problème de performance avec les dates sous Oracle

Message par Phil »

Merci à Guillaume pour sa question :

"J'ai une requête comportant ça dans la clause WHERE :

REF.ECCO_DATE_IMPUTATION >= TIMESTAMP'2019-01-01 00:00:00.000000' AND REF.ECCO_DATE_IMPUTATION <= TIMESTAMP'2019-01-31 23:59:59.999999'

La colonne ECCO_DATE_IMPUTATION est de type DATE. Les performances sont mauvaises sous Oracle car l'index sur la colonne n'est pas utilisé alors que le critère est excellent. Comment faire pour avoir une syntaxe commune et des perfs correctes avec Oracle et PostgreSQL ?"


Réponse :

L'index sur la colonne n'est pas utilisé avec Oracle car une conversion implicite est appliquée sur la colonne REF.ECCO_DATE_IMPUTATION pour transformer la colonne DATE en TIMESTAMP. L'idéal est de comparer des DATE avec des DATE, des TIMESTAMP avec des TIMESTAMP.
Une écriture possible OK avec Oracle et PostgreSQL peut être :

Code : Tout sélectionner

REF.ECCO_DATE_IMPUTATION >= DATE'2019-01-01'  AND REF.ECCO_DATE_IMPUTATION  < DATE'2019-02-01'
Si cette colonne doit comporter des informations heures/minutes/secondes, il faudrait que cette colonne soit de type TIMESTAMP à la fois sous Oracle et PostgreSQL pour être dans le standard SQL. La syntaxe que tu as indiquée serait alors OK. Cette syntaxe pourrait aussi être utilisée :

Code : Tout sélectionner

REF.ECCO_DATE_IMPUTATION >= TIMESTAMP'2019-01-01'  AND REF.ECCO_DATE_IMPUTATION  < TIMESTAMP'2019-02-01'
Pour rappel, il ne faut idéalement pas utiliser les fonctions TO_DATE ou TO_TIMESTAMP avec PostgreSQL lorsque ce n'est pas nécessaire afin d'avoir des performances optimales dans tous les cas, cf https://pgphil.ovh/volatility_10_01.php
Cdlt. Phil - pgphil.ovh

Répondre