Re: Optimization of this SQL sentence - Mailing list pgsql-performance

From Alexander Staubo
Subject Re: Optimization of this SQL sentence
Date
Msg-id EFB9AB5E-C089-4314-BD32-BCEDDFD3EA02@purefiction.net
Whole thread Raw
In response to Optimization of this SQL sentence  (Ruben Rubio <ruben@rentalia.com>)
Responses Re: Optimization of this SQL sentence
List pgsql-performance
On Oct 17, 2006, at 17:29 , Mario Weilguni wrote:

> Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo:
>> Lastly, note that in PostgreSQL these length declarations are not
>> necessary:
>>
>>    contacto varchar(255),
>>    fuente varchar(512),
>>    prefijopais varchar(10)
>
> Enforcing length constraints with varchar(xyz) is good database
> design, not a
> bad one. Using text everywhere might be tempting because it works,
> but it's
> not a good idea.

Enforcing length constraints is generally a bad idea because it
assumes you know the data domain as expressed in a quantity of
characters. Off the top of your head, do you know the maximum length
of a zip code? A street address? The name of a city?

In almost all cases the limit you invent is arbitrary, and the
probability of being incompatible with any given input is inversely
proportional to that arbitrary limit.

Encoding specific length constraints in the database makes sense when
they relate explicitly to business logic, but I can think of only a
few cases where it would make sense: restricting the length of
passwords, user names, and so on. In a few cases you do know with
100% certainty the limit of your field, such as with standardized
abbreviations: ISO 3166 country codes, for example. And sometimes you
want to cap data due to storage or transmission costs.

The length constraint on text fields is primarily a historical
artifact stemming from the way databases have traditionally been
implemented, as fixed-length fields in fixed-length row structures.
The inexplicable, improbable space-padded (!) "character" data type
in ANSI SQL is a vestige of this legacy. PostgreSQL's variable-length
rows and TOAST mechanism makes the point moot.

Quoth the PostgreSQL manual, section 8.3:

> There are no performance differences between these three types,
> apart from the increased storage size when using the blank-padded
> type. While character(n) has performance advantages in some other
> database systems, it has no such advantages in PostgreSQL. In most
> situations text or character varying should be used instead.

Alexander.

pgsql-performance by date:

Previous
From: Alexander Staubo
Date:
Subject: Re: Optimization of this SQL sentence
Next
From: Mario Weilguni
Date:
Subject: Re: Optimization of this SQL sentence