Thread: CHAR vs VARCHAR w/TOAST

I read in the Changes list for 7.1 the following line:

CHAR() no longer faster than VARCHAR() because of TOAST
(Tom)

Does this mean that scanning is just as fast using VARCHAR
as CHAR?  I was always taught to use CHAR on columns that I
needed speedier search results.  What are the facts?

Brent

"Brent R. Matzelle" <bmatzelle@yahoo.com> writes:
> Does this mean that scanning is just as fast using VARCHAR
> as CHAR?  I was always taught to use CHAR on columns that I
> needed speedier search results.  What are the facts?

See recent discussions on this point.  There is no speed advantage to
CHAR() --- there never was more than a minuscule advantage to it in
Postgres, and that's now gone entirely.  However, if you are taking
naturally variable-width data and forcing it into CHAR(n) via
blank-padding, then you are paying very real costs in disk space and
I/O time for all those extra blanks.

To me, the bottom line is: use the data type whose semantics fit your
data (for textual data, that could be char(n), varchar(n), or text,
depending on what you want to enforce about length limits).  Anything
else is at best micro-optimization and more likely folly.

            regards, tom lane