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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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/)
From | Date | Subject | |
---|---|---|---|
Next Message | Együd Csaba | 2004-06-27 06:57:55 | Re: Trigger isn't fired |
Previous Message | wespvp | 2004-06-27 01:43:50 | Re: enable thready safety on Mac OS X 10.3.4 |