Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai la table suivante :
CREATE TABLE evt
(
evt_id numeric(10,0) NOT NULL,
date_creation character varying(23) NOT NULL, -- Date de creation de l'evenement au format 'yyyy/mm/dd hh24:mi:ss:ccc'
CONSTRAINT pk_evt PRIMARY KEY (evt_id)
)
On insère des lignes au fur et à mesure avec à chaque fois now() pour la colonne date_creation. Ce qui conduit à ce que la colonne date_creation soit ordonnée (Soient evt_id1 et evt_id2, si evt_id1<evtid2 alors date_creation1<=date_creation2). Le moteur postgresql, pour rechercher une date, ne devrait plus faire un seqscan mais une recherche dichotomique.
Mes 2 questions :
* comment indiquer au moteur postgres que la colonne est ordonnée ?
* serait-ce beaucoup plus performant qu'un index sur la colonne date_creation ou sur un substring de date_creation (seulement yyyy/mm/dd) ?
Hors ligne
Une recherche dichotomique ? Les enregistrements ne sont pas triés dans une base de données relationnelle. En tout cas il n'y a aucune garantie de tri. Vous ne pourrez donc pas lui indiquer, vu que c'est contraire à tout ce qu'on veut habituellement faire avec un SGBD relationnel (définir des enregistrements indépendants entre eux, des relations, etc…).
Le reste de la question n'a plus beaucoup de sens, une fois ceci expliqué. Si vous voulez accéder rapidement à un enregistrement donné, par un critère, c'est par un index. D'ailleurs vous avez un type date, qui est bien plus approprié qu'un type varchar pour ça: il est bien plus compact, et vous avez des fonctions et opérateurs directement appropriés (comme comparer des dates, pas des chaînes de caractères).
Si ce que vous décrivez est vraiment ce que vous voulez vraiment faire (ce n'est pas forcément une mauvaise idée), ce n'est pas d'une base de données relationnelle que vous avez besoin, c'est d'un fichier texte, ou un fichier séquentiel indexé par exemple, qui seront bien plus performants dans ce genre de contexte précis. Un SGBD n'est pas peut-être pas le bon outil.
Sinon, si les enregistrements sont réellement ordonnés, ce sera collecté dans les statistiques du moteur (il stocke la corrélation entre les enregistrements consécutifs), et il saura que les accès par l'index sont bien moins chers que dans le cas d'une table tout en «désordre».
Pourquoi voulez vous faire des dichotomies ? L'accès par index n'est pas assez performant ?
Marc.
Hors ligne
Bonjour,
Merci pour votre longue réponse. Nous allons utiliser un index :
CREATE INDEX date_dun_horodatage_fk
ON horodatage
USING btree
(substr(date::text, 1, 10));
Une recherche par dichotomie sur 50 000 000 éléments est réalisée en 25 itérations, donc très rapide. Mais un mécanisme équivalent existe sur les index.
Pour le problème de la date enregistrée sous un format texte, c'est historique de la conception initiale de la base et cela nous pose régulièrement des soucis.
Hors ligne
Pages : 1
