Alvaro Herrera <alvherre@protecne.cl> writes:
> According to "Postgres: Introduction and Concepts", varchar is slower
> than char. So if you (like me) want to use char and get rid of the
> padding spaces, you may use a regex replacement, as in
> while (@row=$result->fetchrow)
> {
> $row[0] =~ s/[\s]+$//;
> }
I can confidently assure you that the performance differential between
char and varchar is small enough to be swamped out by invocation of
functions like the above. (Besides, it's gone entirely for PG 7.1.)
And that's just based on pure CPU-time considerations, without regard
for disk-transfer-time and cache-space-wastage issues. Padding
spaces can easily cost you FAR more along those dimensions than you
can ever hope to save from having a fixed tuple layout.
IMHO, 'char(n)' is suitable for extremely small values of n where
you *know* that space-padding is not the normal case. Almost the
only natural example I can think of is two-letter USA postal
abbreviations for states (such as PA in my address). Otherwise
use 'varchar(n)' if your application has a natural upper bound on
sensible string lengths, or 'text' if you can't instantly pick a
specific value of the upper limit 'n'.
regards, tom lane