Ok, je suis probablement en retard pour la fête, MAIS...
IL N'EST PAS NÉCESSAIRE DE REDIMENSIONNER LA COLONNE DANS VOTRE CAS !
Postgres, contrairement à d'autres bases de données, est suffisamment intelligent pour utiliser juste assez d'espace pour la chaîne (même en utilisant la compression pour les chaînes plus longues), donc même si votre colonne est déclarée comme VARCHAR(255) - si vous stockez des chaînes de 40 caractères dans la colonne, l'espace utilisé sera de 40 octets + 1 octet de surcharge.
Le besoin en mémoire pour une chaîne courte (jusqu'à 126 octets) est de 1 octet plus la chaîne de caractères proprement dite, qui comprend l'espace de remplissage dans le cas de de caractère. Les chaînes plus longues ont 4 octets de surcharge au lieu de 1. Les chaînes plus longues sont automatiquement compressées par le système, de sorte que la besoin physique sur le disque peut être moindre. Les valeurs très longues sont également également stockées dans des tables d'arrière-plan afin de ne pas interférer avec les l'accès rapide aux valeurs plus courtes des colonnes.
( http://www.postgresql.org/docs/9.0/interactive/datatype-character.html )
La spécification de la taille en VARCHAR est uniquement utilisée pour vérifier la taille des valeurs qui sont insérées, elle n'affecte pas la disposition du disque. En effet, Les champs VARCHAR et TEXT sont stockés de la même manière dans Postgres. .
13 votes
Juste pour être clair : tu sais, que
resizing
ne fera pas en sorte que la table occupe moins d'espace ?1 votes
Je veux dire que la colonne aura une taille maximale de 40 caractères (donc octets) au lieu de 255 ?
22 votes
Si vous dites
varchar(255)
à PostgreSQL alors il no allouer 255 octets pour une valeur dont la longueur réelle est de 40 octets. Il allouera 40 octets (plus quelques frais généraux internes). La seule chose qui vabe changed by the
ALTER TABLE` est le nombre maximum d'octets que vous pouvez stocker dans cette colonne sans obtenir une erreur de PG.1 votes
A propos du transparent que A.H. a mentionné : Quel est l'overhead pour varchar(n) ?
2 votes
Consultez la réponse ici pour une mise à jour dba.stackexchange.com/questions/189890/