Re: type de donnée et b

From: Pierre Didelon <pdidelon(at)cea(dot)fr>
To: andy petrella <andy(dot)petrella(at)gmail(dot)com>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: type de donnée et b
Date: 2005-10-12 09:23:44
Message-ID: 434CD620.9010802@cea.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

andy petrella wrote:

>
> Mais par contre qu'appelle tu padding dans un int4 où justtement le
> nombre de bytes est précisé dans le type ?
Euhhhh!
Y fo que je m'explique ;-)

C'est pas le padding dans un type de données mais entre des type différents.
Et bien sûr tout dépend de la manière dont postgres stocke les données,
et je n'ai aucune idée la dessus et je ne sais pas trop où regarder.
Si les données sont stockées par colonnes... aucun problème. Cela paraît
bizarre mais c'est peut être (sans doute?) ce qui est fait!
Si les données sont stockées par lignes ou tuples et qu'elles contiennent
des types différents comment sont rangés les différents attributs sur disque?
Si pour des besoins d'alignement mémoire et optimisation des transferts disques
lors des types différents se suivent et qu'ils pourraient ne pas être "alignés"
en mémoire y a t il introduction d'un remplissage pour réalignement?
Y a t il alors une manière optimum de déclarer une table en fonction de l'ordre
des tailles des différents types de données?

Par example si il y a remplissage pour alignement des int et des real
sur des adresses "4 octet" et des double et des bigint sur des adresses "8 octet"
au lieu de :
CREATE TABLE mytable (
index smallint,
valeurcodeur int,
code_donnée smallint,
pression double precision,
temperature real,
horloge bigint,
code_mesure smallint,
temps time )
qui pourrait donner ça (chaque octet, donnée = X, remplissage = .,
| adresse en octet multiple de 8)
XX..XXXX|XX......|XXXXXXXX| XXXX....|XXXXXXXX|XX......|XXXXXXXX
il vaudrait mieux déclarer
CREATE TABLE mytable (
index smallint,
code_donnée smallint,
valeurcodeur int,
pression double precision,
horloge bigint,
temps time,
temperature real,
code_mesure smallint )
où il n'y aurait pas de remplissage!

Bon! Vu les perf de postgres je ne pense pas que tant d'espace vide soit gaché ;-)
Mais keskice passe? j'aimerais comprendre :-( ;-) :-D
Y a kelkun ki sait?
Ou qui sait ou trouver ces infos...
Pure curiosité... pour le moment, et peut être malsaine :-(
Cordialement,
PiR

> La question ce poserait à mon
> sens plus pour un bytea ou plutôt un blob, lui qui n'a pas de structure
> interne définie à priori.
>
> Par contre, ça pourrait être intéressant d'avoir la doc dessus,
> peut-être pour établir, en fonction de leur politique, un meilleur
> dispatching sur les disques
c'est toujours intérressant (et qqfois réconfortant) de savoir ;-)
>
> andy
>

In response to

Responses

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Daniel Verite 2005-10-12 10:24:17 Re: type de donnée et b
Previous Message Guillaume BARTHE 2005-10-12 08:36:21 Appel de fonction dans une fonction