Vous n'êtes pas identifié(e).
Bonjour, sur une table qui contiendra quelques millions de lignes, je lancerai des requetes SELECT avec (...) WHERE type_obj =
ma question : si je défini type_obj comme integer (de 0 à 4) cela aura-t-il un impact significatif en performance par rapport à un type_obj en varchar(2) (AA, BB, CC, DD, EE)
meme question entre integer et char(1)
La config matérielle est plutôt light (hébergement virtualisé de base)
Merci !
Dernière modification par ilrico (05/06/2011 17:01:50)
Hors ligne
Ça ne sera probablement pas mesurable. Les opérations de chaîne et sur les int sont parmi les plus rapides. Le int sera un peu plus rapide quand même, mais je doute que vous le sentiez.
Choisissez plutôt un type qui modélise ce que vous voulez faire, et qui soit facile à comprendre: si votre code sur 2 lettres est plus lisible, choisissez ça à un entier.
Dernière modification par Marc Cousin (05/06/2011 17:23:50)
Marc.
Hors ligne
Les littéraux ont besoin de plus de traitement que les numériques pour toutes comparaisons du simple fait de la gestion de la collation (sensibilité à la casse, aux accents...) qui induit un extra overhead systématique lors des comparaisons.
En sus les données de tailles variables, comme les VARCHAR, stockent la taille réelle de la données en sus soit 2 ou 3 octets supplémentaires.
Donc un VARCHAR(2) fait entre 4 et 5 octets, soit plus qu'un integer.
Enfin les VARCHAR sont plus complexes à retrouver, car étant, de par leur nature, avec une taille variable, il faut parcourir toutes les colonnes précédente de la ligne de la table pour en lire la valeur, ce qui n'est pas le cas des numériques qui sont de taille fixe et regroupés au début de la ligne physique de la table (slot) et directement accessible par un offset calculé par rapport au début de la ligne.
En conclusion, les numériques sont toujours systématiquement plus rapide dans tous les cas de figure et si vous voulez les meilleures performances, alors il faut prendre un entier de la taille exacte du mot du processeurs, soit INT sur 32 bits et BIGINT sur 64 bits, car vous n'aurez ni a gérer une double lecture (cas du BIGINT sur OS 32 bits => 100 % de durée supplémentaire en général) ni à vérifier les bits de poids haut pour renvoyer une erreur de dépassement de capacité (cas du INT sur OS 64 bits => de 2 à 5 % de durée supplémentaire).
A +
Dernière modification par SQLpro (05/06/2011 22:23:23)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
ok, merci à tous les deux pour votre réponse.
Hors ligne
ce qui n'est pas le cas des numériques qui sont de taille fixe et regroupés au début de la ligne physique de la table (slot) et directement accessible par un offset calculé par rapport au début de la ligne
Pas sous PostgreSQL pour le "regroupage en début de ligne physique".
Guillaume.
Hors ligne
Ah justement ça m'évite de créer un nouveau thread ! La question que je voulais poser ce matin est la suivante :
"La place des colonnes est-elle importante sous PostgreSQL ?", car en effet il me semble que vous certaines db il est fortement recommandé de placer les colonnes de type de taille fixe au début, et les type variables (text, varchar) à la fin.
Visiblement, d'après ce que gleu indique, PostgreSQL ne regroupe pas automatiquement les types fixes en debut de ligne, donc j'en deduis que la place des colonnes suivant leur type influe directement sur les performances.
Si oui, l'impact est-il vraiment mesurable sur une table qui fait < 1 Go ?
Hors ligne
Pour une petite table, c'est non mesurable. Même pour une grosse table, c'est très rare qu'on s'embête avec ce détail, sauf si vraiment on veut gratter les derniers % sur des entrées/sorties disque par exemple.
Et effectivement, les "petites" valeurs peuvent être regroupées si elles sont consécutives dans la table. Les infos d'alignement de chaque type sont dans pg_type (colonne typalign): on a pour chaque type sa contrainte d'alignement. Par exemple, un type qui a comme contrainte d'alignement d (double) devra être aligné sur 8 bits…
Marc.
Hors ligne
Ah justement ça m'évite de créer un nouveau thread ! La question que je voulais poser ce matin est la suivante :
"La place des colonnes est-elle importante sous PostgreSQL ?", car en effet il me semble que vous certaines db il est fortement recommandé de placer les colonnes de type de taille fixe au début, et les type variables (text, varchar) à la fin.
Visiblement, d'après ce que gleu indique, PostgreSQL ne regroupe pas automatiquement les types fixes en debut de ligne, donc j'en deduis que la place des colonnes suivant leur type influe directement sur les performances.
Si oui, l'impact est-il vraiment mesurable sur une table qui fait < 1 Go ?
Oui, sur des grosses tables si vous faites beaucoup d'UPDATE....
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
En quoi le fait qu'il y ait beaucoup d'update aurait davantage d'impact ?
Marc.
Hors ligne
