Bonjour!
 
J'ai une expérience plutôt nulle en optimisation de base de données. J'aimerais quelques informations.
 
J'ai une table T de 340k lignes (ca peut facilement dépasser le million).
J'ai un champs D de la forme AAAAMMJJ.
Seulement en fait je n'ai que 2 années différentes.
 
Comment je pourrais récupérer efficacement ces deux années ?
Rien qu'un "select distinct" sur le champs D prend 3.8 secondes et me retourne 731 lignes (forcément: 2x365)
 
Bricoler un "select distinct" sur les 4 premiers caractères du champ D, c'est envisageable ?
 
Pour info je remplis la bd avec un fichier txt structuré. S'il n'y a pas de solution correcte, je vais voir si je peux pas couper le champs D en deux: AAAA && MMJJ    
 
Merci de votre aide.

a priori, je dirais que le plus rapide serait deux requètes, vu ton cas, avec un index sur la date.
select max(D) from T et select min(D) from T

mais bon, si tu sais que tu n'as jamais que deux années, faudrait peut-être voir à les hardcoder quelque part ou duppliquer l'information.

stock avec un format numérique. pas texte

on peut supposer que c'est déjà le cas (n'est-ce pas? )

Merci à vous  
 
int4 pour la date.
 
Actuellement il se trouve que je n'ai que 2 années différentes, seulement ca peut atteindre une dizaine.
 
Pour le moment c'est moi qui ajoute les données dans la table avec un COPY FROM. Je ferai surement un script d'ajout pour l'utilisateur final.
 
Bon je suppose que le mieux est de mettre ces quelques années dans une table, l'utilisateur devra les rajouter si besoin.

m'enfin, pourquoi un int4?! c'est pas fait pour ça

ben ça rentre très bien. tu peux stocker en pseudo DCB
 
4 * 4 bits : année
2 * 4 bits : mois
2 * 4 bits : jour

Le plus efficace serait de rajouter un champs avec uniquement l'année dedans, malgré le fait qu'il y aura duplication de données.

 
oui, parfois il faut oublier la théorie et songer a la pratique... une ptite duplication de données peut entrainer une hausse significative des perfs...

tout à fait, la normalisation n'est pas synonyme de performance. Dernormaliser, c'est efficace quand c'est bien pensé.

De toute façon, ce qui plombe les perfs, c'est le TABLE SCAN imposé par la recherche des DISTINCT.
 

 
(Oracle like)
 
Avoir l'année dans un champ à part va pas changer grand chose, y a toujours obligation de faire un TABLE SCAN.
 
Le seul moyen de réduire la durée d'exécution serait de maintenir dans une table à part par exemple, la liste des différentes années utilisées ... mais ça suppose de vérifier avant chaque ajout/update dans la table T si l'année existe dans cette table à part, etc. (donc une perte de perfs lors du remplissage de la table T).

pourquoi pas sous forme numérique ?
 
select ... FROM T where date > 20020000;
 
?

Je ne suis pas l'auteur de la structure de la base.  
INT4, j'ai laissé comme c'était.
Je vais opter pour une table contenant les années, car une fois les données insérées, elles sont seulement lues, il n'y a pas un besoin de modification. Et l'insertion se fera de l'ordre d'une fois par an je suppose.
Un script à l'insertion fera ce qu'il faut pour éventuellement ajouter les années concernées. Cette perte de temps n'est pas importante.
 
Merci à vous.

moi perso, je préfère laisser de côté les perfs et pensé à la lisibilité :
 
select distinct to_char(to_date(d, 'YYYYMMDD', 'YYYY') from latable
 
Au moins on comprends ce qu'on fait. Et d'un point de vue perfs, tu dois avec 2 ms d'écart par rapport à un substr() classique.
 
PS: par contre, le choix du INT c'est total n'importe quoi. une date, c'est soit un type date, soit un char(8), ça évite de se prendre des cast dans tous les sens au premier traîtement sur les dates

int(10) et timestamp