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/) ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
