> -----Original Message-----
> From: Alvaro Herrera [mailto:alvherre@alvh.no-ip.org]
> Sent: Thursday, September 01, 2005 3:34 PM
> To: Merlin Moncure
> Cc: Matthew Sackman; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Massive performance issues
>
> On Thu, Sep 01, 2005 at 02:04:54PM -0400, Merlin Moncure wrote:
> > > Table "public.address"
> > > Column | Type | Modifiers
> > > ----------------------+------------------------+-----------
> > > postcode_top | character varying(2) | not null
> > > postcode_middle | character varying(4) | not null
> > > postcode_bottom | character varying(7) | not null
> >
> > consider making above fields char(x) not varchar(x) for small but
> > important savings.
>
> Huh, hang on -- AFAIK there's no saving at all by doing that. Quite
the
> opposite really, because with char(x) you store the padding blanks,
> which are omitted with varchar(x), so less I/O (not necessarily a
> measurable amount, mind you, maybe even zero because of padding
issues.)

You are right, all this time I thought there was a 4 byte penalty for
storing varchar type and not in char . So there is no reason at all
to use the char type?

Merlin


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match