From: | Tim Tassonis <timtas(at)cubic(dot)ch> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Crystal <support(at)conceptpatterns(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: The speed problem of Varchar vs. Char |
Date: | 2007-07-17 09:46:00 |
Message-ID: | 469C8FD8.8090200@cubic.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>
> Once upon a time, in the days of 80-column punch cards and no
> variable-length character encodings, there were databases that could
> handle fixed-width character fields a bit faster than variable-width.
> That doesn't apply to Postgres. There is no, none, nada performance
> advantage to char(n), and you should never use it unless your
> application data clearly demands a specific field width.
I still often use char(n) a lot, mainly for documentation purposes. If a
column will only ever hold exactly a fixed length string (status codes
and stuff), it looks better in the datamodel to use char(n) IMHO.
Tim
From | Date | Subject | |
---|---|---|---|
Next Message | Zlatko Matić | 2007-07-17 09:56:52 | ERROR: a column definition list is required for functions returning "record" |
Previous Message | Nis Jørgensen | 2007-07-17 08:22:21 | Re: pg_dump without blobs |