Discussion :

[clavier12AZQSWX]

bonjour,


quelqu'un m'a glissé à l'oreille que postgres compare plus vite 2 chaines que 2 dates ? est-ce vrai ? je n'ai pas assez de données date dans une table pour vérifier...

En gros, il m'a dit qu'il vaut mieux faire des WHERE to_char(madate)='mon autre date' que d'écrire WHERE madate=mon_autre date

il m'a expliqué que pg avant toute opération/expression de date vérifie toujours la date avant de faire la comparaison et que cette vérification prend bcp de temps (alors qu'il n'y a pas de vérification lors d'une comparaison de chaine)

j'ai vérifié c'est vrai : si on fait where a='2012-02-31' alors pg crie bien à l'erreur car le 31 fév n'existe pas. Donc oui il ya bien une vérification avant la comparaison. Du coup si on a 2 dates en opérande, pg fait 2 vérif.
Alors qu'avec une comparaison de 2 chaines, il n'a aucune vérification à faire car une chaine peut être NIMPORTEQUOI.

par pour savoir si le coût d'une conversion en chaine est moindre que le coût d'une vérification de date..bun là, je sêche, je ne sais pas comment vérifier cela.

il faudra avoir une table avec 1millions de date et faire un test avec et sans conversion en string.


qu'en pensez-vous ?

[SQLpro]

Il vous a répondu n'importe quoi !!!

Visiblement il en est resté à Cobol et devrait éviter de toucher à un SGBDR !!!

Cela rejoint ce post :
http://www.developpez.net/forums/d11...ortant-2012-a/

Peut être s'agit-il du même qui sévit un peu partout !!!!

A +

Dans les bases de données, les données ont des types de données de type DATE, car SQL est un langage typé. Les chaines de caractères ont aussi des types qui sont de la famille des CHAR, VARCHAR, NCHAR et NVARCHAR avec une longueur. Ainsi un CHAR n'est pas de même type qu'un VARCHAR et un CHAR(5) n'est pas non plus du même type qu'un CHAR(8). Dans tous les cas ou une opération de comparaison intervient il y aura un transtypage implicite vers le type le plus "large"
Comparer une colonne DATE à une chaine de caractère suppose donc de transformer TOUTES LES DONNÉES de votre table en chaine AVANT de pouvoir faire la comparaison. En sus, avec un littéral il faut rajouter la gestion de la collation qui permet de prendre en compte ou non la casse ou les caractères diacritique. Donc de l'extra overhead dans les opérations de comparaison, que des types date ou nombre n'ont pas !

Enfin, avec ce transtypage à la volée, le SGBDR ne peut plus utiliser d'index s'il y en a un ! Car un index c'est un "tri", or un tri de nombre n'est pas rangé de la même manière qu'un tri de littéral !!!
Résultat cela tue les performances, car il faudra que le SGBDR balaye toute la table ligne après ligne pour trouver l'occurrence, alors qu'avec un index, il l'a trouve immédiatement !

Bref, au lieu d'écouter des CONS car il faut appeler un chat un chat, apprenez ce qu'est un SGBDR et comment ça fonctionne. Mon site web comme mes bouquins sont là pour vous y aider.

A +

,

[estofilo]

j'ai vérifié c'est vrai : si on fait where a='2012-02-31' alors pg crie bien à l'erreur car le 31 fév n'existe pas

Et c'est bien la moindre des choses. Tout ce que ça montre, c'est qu'une chaine litérale transtypée à la volée en date est testée pour contrôler que c'est une date valide.
Mais ça va être fait une seule fois pour toute la requête.
Pour la valeur à gauche de la comparaison, celle qui est lue dans une colonne qui est déjà de type date, il n'y a aucun transtypage à faire donc l'idée qu'il serait plus rapide de la transformer en chaine de caractères n'a pas de sens.