Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sebastien Lardiere
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
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.
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 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
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 :)
- 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
"Etienne" a écrit dans le message de news: 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.
"Etienne" <etienne@tlk.fr> a écrit dans le message de news:
4c4febcf$0$2871$426a74cc@news.free.fr...
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.
"Etienne" a écrit dans le message de news: 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.
