[gull] Pas de parcours d'index postgresql

[Daniel Cordey]

On Wednesday 10 June 2009 10:01:08 Frédéric Benninger wrote:

> SELECT * FROM temperature ORDER BY date DESC LIMIT 1;
> Durée totale d'exécution de la requête :30 ms.

Et quel est le temps d'execution si tu fais :

SELECT * FROM temperature ORDER BY date ASC LIMIT 1;

> J'ai un peu chercher comment était déclaré la fonction max (stable,
> volatile, etc. ) mais je ne l'ai pas trouvé

Je ne suis de loin pas specialiste postgres, mais j'ai deja constate que 
l'ordre de tri peut avoir une importance enorme sur les performances des bases 
de donnees. Je sais bien que la commande au-dessus ne donne pas le resultat 
escompte, mais c'est juste pour savoir si la fonction max ne dependait pas de 
cet ordre. Aussi, tu pourais stocker la date en secondes, plutot qu'en 'date', 
ce qui te permettrait d'indexer un entier plutot qu'une entite date plus 
complexe. MySQL traite aussi les dates de maniere parfois surprenante; toute 
operation sur une colonne de type 'date', meme indexe, peut s'averer 
couteuse... Aussi, il n'est pas recommande d'appeler une colonne 'date'. Cela 
interfere souvent avec le mot reserve 'date'; et oblige a manipuler le nom de 
la colonne entre `` dans les commandes SQL (sous peine d'avoir des 
surprises)...

dc