> -----Original Message----- > From: Alvaro Herrera [mailto:[EMAIL PROTECTED] > 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