Skip site navigation (1) Skip section navigation (2)

Re: Datatype sizes; a space and speed issue?

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Joel Matthew <rees(at)ddcom(dot)co(dot)jp>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Datatype sizes; a space and speed issue?
Date: 2004-06-27 06:45:04
Message-ID: 20040627064504.GC13306@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-general
On Wed, Jun 23, 2004 at 02:43:06PM +0900, Joel Matthew wrote:
> > We used to have some attempts at optimizing on the assumption that
> > char(n) fields were physically fixed-width, but we gave it up as a
> > bad job several major releases back ... it was never more than a
> > very marginal optimization anyway ...
> 
> Does that mean that PostGreSQL fixes character width at thirty-two bits,
> or that it uses UTF-8, or that it just stores what it gets?

It'll use utf8 if configured to do so; it'll just store what it gets if
configured as SQL_ASCII (it isn't really ASCII); or it will convert from
the client encoding to the server encoding before storing, if they are
different.

> (Checked chapter 8.3 in the manual, didn't see the answer there. Not
> that I really want to know. With Unicode, trying to optimize record
> sizes for char/text fields is a little like trying to play Russian
> Roulette. Wait, is that no longer politically correct? Should it be
> called six-chamber roulette, now? Don't want to offend anyone.)

Of course, the optimization could have only worked on fixed-width
encodings (not utf8 -- maybe possible with utf32, but Postgres doesn't
support that AFAIK), but since current versions enable multibyte by
default there's really no point in trying.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I would rather have GNU than GNOT."  (ccchips, lwn.net/Articles/37595/)


In response to

pgsql-general by date

Next:From: Együd CsabaDate: 2004-06-27 06:57:55
Subject: Re: Trigger isn't fired
Previous:From: wespvpDate: 2004-06-27 01:43:50
Subject: Re: enable thready safety on Mac OS X 10.3.4

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group