Re: extra spaces

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)protecne(dot)cl>
Cc: pgsql-general(at)postgresql(dot)org, php-db(at)lists(dot)php(dot)net
Subject: Re: extra spaces
Date: 2000-12-20 06:47:17
Message-ID: 4571.977294837@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alvaro Herrera <alvherre(at)protecne(dot)cl> writes:
> According to "Postgres: Introduction and Concepts", varchar is slower
> than char. So if you (like me) want to use char and get rid of the
> padding spaces, you may use a regex replacement, as in

> while (@row=$result->fetchrow)
> {
> $row[0] =~ s/[\s]+$//;
> }

I can confidently assure you that the performance differential between
char and varchar is small enough to be swamped out by invocation of
functions like the above. (Besides, it's gone entirely for PG 7.1.)

And that's just based on pure CPU-time considerations, without regard
for disk-transfer-time and cache-space-wastage issues. Padding
spaces can easily cost you FAR more along those dimensions than you
can ever hope to save from having a fixed tuple layout.

IMHO, 'char(n)' is suitable for extremely small values of n where
you *know* that space-padding is not the normal case. Almost the
only natural example I can think of is two-letter USA postal
abbreviations for states (such as PA in my address). Otherwise
use 'varchar(n)' if your application has a natural upper bound on
sensible string lengths, or 'text' if you can't instantly pick a
specific value of the upper limit 'n'.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Lockhart 2000-12-20 07:17:00 Re: Re: Generating HISTORY file
Previous Message Bruce Momjian 2000-12-20 03:20:35 Re: Re: Generating HISTORY file