postgresql champs boolean et espace disque

Le
Etienne
salut

j'aimerai savoir s'il existe une information concernant l'agencement des
champs de bit en mémoire.

J'ai une table avec plein de booleen
CREATE TABLE t1 (
"id" serial,
"b1" boolean,
"b2" boolean,
"b3" boolean,
"b4" boolean,
"b5" boolean,
"b6" boolean,
"b7" boolean
);

J'envisage de la remplacer par
CREATE TABLE t2 (
"id" serial,
"fb" integer,
);

ou je gèrerai les bit moi même.

SELECT * FORM t1 WHERE b2 = 'f';
serait equivalent à
SELECT 0 FROM t2 WHERE (fb & 2) = 0

Ma question est y a t-il un interêt a faire ça:
- niveau mémoire
- niveau performance

je précise qu'a priori je n'ai pas besoin de mettre un index sur une des
colonnes, ce qui pourrait effectivement poser problème.

Merci
Etienne.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sebastien Lardiere
Le #22411761
Le 28/07/2010 10:37, Etienne a écrit :
salut

j'aimerai savoir s'il existe une information concernant l'agencement des
champs de bit en mémoire.

J'ai une table avec plein de booleen
CREATE TABLE t1 (
"id" serial,
"b1" boolean,
"b2" boolean,
"b3" boolean,
"b4" boolean,
"b5" boolean,
"b6" boolean,
"b7" boolean
);

J'envisage de la remplacer par
CREATE TABLE t2 (
"id" serial,
"fb" integer,
);

ou je gèrerai les bit moi même.

SELECT * FORM t1 WHERE b2 = 'f';
serait equivalent à
SELECT 0 FROM t2 WHERE (fb & 2) = 0

Ma question est y a t-il un interêt a faire ça:
- niveau mémoire
- niveau performance

je précise qu'a priori je n'ai pas besoin de mettre un index sur une des
colonnes, ce qui pourrait effectivement poser problème.




Bonjour,

Dans PostgreSQL, le type boolean utilise un octet de stockage, et non
pas un bit, comme on pourrait le croire.

Donc, on pourrait penser que l'utilisation d'un entier ( 4 octets ) pour
stocker 8 boolean est intéressante ( on divise par 2 ).

Par contre, l'exploitation des valeurs comprises dans l'entier me parait
extremement fastidieuse.

En fait, il faut se poser les bonnes questions :

- quelle quantité de données voulez-vous stocker ? combien de lignes
dans cette table ?
- Allez vous vraiment atteindre des limites du matériel en stockage (
disques, RAM ) ?
- Avez vous déjà rencontré des problèmes de performance ?

Je demande ça, parce que je ne voudrais pas que vous essayiez de
résoudre un problème que vous n'avez pas.

En fait, sauf volume énorme, PostgreSQL s'en sortira très bien avec des
boolean

Par ailleurs, il est tout à fait possible d'utiliser des expressions
dans la définition d'un index, donc, de créer un index par boolean dans
l'entier, ça n'est donc pas un problème.


--
Sébastien
Etienne
Le #22411931
Le 28/07/2010 16:56, Sebastien Lardiere a écrit :
- quelle quantité de données voulez-vous stocker ? combien de lignes
dans cette table ?
- Allez vous vraiment atteindre des limites du matériel en stockage (
disques, RAM ) ?
- Avez vous déjà rencontré des problèmes de performance ?



En fait non.
J'en ai pas vraiment besoin.
Ces bit sont de bit de droits

Droit en Lecture, Ecriture, ...
Je fais dessus au final des OR ou des AND.
Mon idée était de ne faire qu'une seule operation pour tous les bits
d'un coup.

Mais bon vous avez raison, c'est fastidieux.
J'ai testé vite fait, et je suis vite arrivé aux limites du modèle.
J'ai rapidement fait marche arrière :)

Etienne
Williamhoustra
Le #22412771
"Etienne" 4c4febcf$0$2871$
salut

j'aimerai savoir s'il existe une information concernant l'agencement des
champs de bit en mémoire.

J'ai une table avec plein de booleen
CREATE TABLE t1 (
"id" serial,
"b1" boolean,
"b2" boolean,
"b3" boolean,
"b4" boolean,
"b5" boolean,
"b6" boolean,
"b7" boolean
);

J'envisage de la remplacer par
CREATE TABLE t2 (
"id" serial,
"fb" integer,
);

ou je gèrerai les bit moi même.



Voui, mais il peut y avoir un os : j'ai lu quelque part, mais ça
s'applique à notre éléphant, que le type integer ne présume en rien de sa
vraie place en bits bien tassés et qu'il peut se réserver le droit de
prendre un tout autre encombrement. Ceci est à envisager sur le 64 bits car
je pense que nous vivons les derniers moments du 32 bits.
Publicité
Poster une réponse
Anonyme