Re: CHAR or VARCHAR

On 22 Mar 2001, at 10:05, Tom Lane wrote:

> There is *no* performance advantage of CHAR(n) over VARCHAR(n).
> If anything, there is a performance lossage due to extra disk I/O
> (because all those padding blanks take space, and time to read).
> 
> My advice is to use CHAR(n) when that semantically describes your data
> (ie, truly fixed-width data, like US postal codes), or VARCHAR(n) when
> that semantically describes your data (ie, variable-width with a hard
> upper bound), or TEXT when that semantically describes your data (ie,
> variable width with no specific upper bound).  Worrying about
> performance differences is a waste of time, because there aren't any.

I wonder if this question of char/varchar is postgresql specific or 
rdbms in general. In any case I did some looking around the web 
and in the end I think the best advice is what Tom says above. 
Here are some pertinent things I found after entering (Index 
Performance Char vs Varchar) in google. 

http://www.swynk.com/friends/mcgehee/developers_tuning_tutorial.
asp

> If the text data in a column varies greatly in length, use a VARCHAR
> data type instead of a CHAR data type. Although the VARCHAR data type
> has slightly more overhead than the CHAR data type, the amount of
> space saved by using VARCHAR over CHAR on variable length columns can
> reduce I/O, improving overall SQL Server performance. 

Forgot URL:

> Several other people at the session who were familiar with the
> performance effects of using char vs. varchar confirmed my advice. One
> person said his team was charged with deploying an application that
> used SQL Server. After deploying the application, the team found that
> it performed terribly. Upon inspecting the database, team members
> discovered that all the fields were varchar. They changed the fields
> to char, and the application now performs fine.

Forgot URL:

> Here's the advice from IBM in from the DB2 Admin guide SC96-9003)
> Copyright IBM Corp. 1982, 1999 " Choosing CHAR or VARCHAR: VARCHAR
> saves DASD space, but costs a 2-byte    
>  overhead for each value and the additional processing required for   
>      varying-length records. Thus, CHAR is preferable to VARCHAR,
>  unless the   space saved by the use of VARCHAR is significant. The
>  savings are not     significant if the maximum length is small or the
>  lengths of the values do not have a significant variation. In
>  general, do not define a column as   VARCHAR(n) unless n is at least
>  18.  (Consider, also, using data          compression if your main
>  concern is DASD savings.  See "Compressing data  in a table space or
>  partition" in topic 2.6.2 for more information.)      
> 
> If you use VARCHAR, do not specify a maximum length that is greater
> than  necessary. Although VARCHAR saves space in a table space, it
> does not save space in an index, because index records are padded with
> blanks to the    maximum length. Note particularly the restrictions on
> columns of strings  longer than 255 bytes; for example, they cannot be
> indexed. These         restrictions are listed in Chapter 3 of DB2 SQL
> Reference."                
> 
> David Seibert
> Compuware Corporation File-AID product planner
> Dave_Seibert@Compuware.com
> 
> 


---------------------------
"Reality is that which, when you stop believing in it, doesn't go
away".               -- Philip K. Dick