From: | Jasen Betts <jasen(at)xnet(dot)co(dot)nz> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Generic design: char vs varchar primary keys |
Date: | 2011-08-05 12:40:19 |
Message-ID: | j1gobj$m5j$1@reversiblemaps.ath.cx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On 2011-08-03, Raj Mathur (=?utf-8?b?4KSw4KS+4KSc?= =?utf-8?b?IOCkruCkvuCkpeClgeCksA==?=) <raju(at)linux-delhi(dot)org> wrote:
> Hi,
>
> Can you point me to any pages that explain the difference between using,
> say CHAR(8) vs VARCHAR(8) as the primary key for a table? Is there any
> impact on the database in terms of:
look in the data types chapter of the manual
> - Speed of indexed retrieval
> - Speed of join from a referencing table
> - Storage (I presume VARHAR(8) would have a slight edge, in general)
> - Any other issue
Unless you need the padding, and/or the length constraints use text.
("usr/share/doc/postgresql-doc-8.4/html/datatype-character.html")
. Tip: There is no performance difference among these three types,
. apart from increased storage space when using the blank-padded type,
. and a few extra CPU cycles to check the length when storing into a
. length-constrained column. While character(n) has performance
. advantages in some other database systems, there is no such advantage
. in PostgreSQL; in fact character(n) is usually the slowest of the
. three because of its additional storage costs. In most situations text
. or character varying should be used instead.
--
⚂⚃ 100% natural
From | Date | Subject | |
---|---|---|---|
Next Message | Jasen Betts | 2011-08-05 12:43:48 | Re: Generic design: char vs varchar primary keys |
Previous Message | Gnanakumar | 2011-08-05 09:07:08 | Re: Calculating relative time/distance from CURRENT_TIMESTAMP |