Re: Speed & Memory Management - Mailing list pgsql-admin

From Tom Lane
Subject Re: Speed & Memory Management
Date
Msg-id 2296.1049224077@sss.pgh.pa.us
Whole thread Raw
In response to Re: Speed & Memory Management  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-admin
Robert Treat <xzilla@users.sourceforge.net> writes:
> Unless your application requires a 30 character limit at the logical
> level, use text.

And if it does, use varchar(30).  I will bet a very good lunch that
char(30) will be a complete dead loss on *every* measure: speed, disk
space, and convenience.

char(N) is not really fixed-width in Postgres, because N is measured
in characters not bytes (which are not the same thing if you use a
multibyte character encoding).  Therefore, there are no optimizations
that could allow it to outperform varchar(N).  When you consider the
extra cost of performing the padding step, the extra storage and I/O
incurred for all those pad blanks, and the client-side headaches of
having to trim the unwanted blanks again, it's just guaranteed to be
a loser.

The only case in which I could recommend char(N) is where you have
application semantics that constrain a field to exactly N characters
(postal codes are one common example).  If the semantics are "at
most N characters", use varchar(N).  If you are picking N out of the
air, don't bother: use text.

            regards, tom lane


pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR: dtoi4: integer out of range
Next
From: "Josh Goldberg"
Date:
Subject: Re: lost tables