Re: indexing on char vs varchar

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: "Beth Gatewood" <beth(at)vizxlabs(dot)com>, "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: <pgsql-sql(at)postgresql(dot)org>
Subject: Re: indexing on char vs varchar
Date: 2002-10-02 17:55:22
Message-ID: 200210021055.22641.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Beth,

> Sorry....I don't understand. The length is at the front of what?

In some RDBMSs, the VARCHAR data type has a 2 or 4-byte indicator of the
length of the stored string before the data itself, while CHAR does not
require this information because it is fixed-length. This makes the CHAR
datatype marginally smaller, and thus faster, than the VARCHAR data type on
those databases. This difference goes back to much older databases and
computers, where every byte of a row counted in terms of performance.

In my experience, even though MS SQL Server still functions this way, the
performance difference between CHAR and VARCHAR is not measurable unless you
are getting close to the 8K data page limit that MSSQL imposes. YMMV.

Postgres does not materially differentiate between CHAR, VARCHAR, and TEXT,
except that CHAR is padded by spaces and VARCHAR often has a length limit.
However, in terms of storage efficiency (and indexing efficiency), they are
identical. In Postgres, the character count is included in all string data
types.

Thus, you should use the data type most appropriate to the data you are
storing, ignoring performance issues. If the data is a fixed-length string
(such as a required zip code) use CHAR; if it's variable but limited, use
varchar; if it's a long description, use TEXT.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Josh Berkus 2002-10-02 17:56:19 Re: indexing on char vs varchar
Previous Message bcschnei 2002-10-02 17:53:29 Re: Stored Procedures