Re: [Pgsql-ayuda] Problema con funciones

On Fri, 20 Jun 2003, Alvaro Herrera Munoz wrote:

> On Fri, Jun 20, 2003 at 08:05:11AM +0200, Antonio Castro wrote:
> > On 19 Jun 2003, Manuel Sugawara wrote:
> >
> > > usas iso-8859-5. Esto es lo bonito de unicode (utf-8 por ejemplo), que
> > > la ? y los caracteres cir?licos, ?rabes, chinos etc pueden convivir
> > > todos juntos, sin embargo algunos caracteres te van a tomar dos o tres
> > > bytes mientras que en las codificaciones iso-8859-X todos los
> > > caracteres toman un solo byte.
> >
> > Me da la impresi?n que esto afecta al rendimiento de los indices
> > sobre campos de tipo char(n).
>
> Pura especulacion, o hiciste mediciones?

Si es pura especulación. Para hacer una pruebecita rápida y mal prefiero
no hacerla. De todas formas según los casos la diferencia de tamaño de
los campos indexados puede ser superior al doble. Sospecho que almenos
en algún caso si pueda representar un menor rendimiento. Es solo sentido
común pero no puedo afirmarlo categoricamente.

> > Con el unicode creo que estos campos
> > pasan a tener un almacenamiento con un n?mero variable de bytes.
> > Sin unicode un char(4) ocupa cuatro bytes nada m?s. No digo que sea
> > un problema grave, pero si lo veo como una desventaja.
>
> Unicode no es la unica codificacion multibyte.

Bueno las otras codificaciones multibyte tendrán el mismo problema.

> Si quieres usar una codificacion mono-byte pero poder usar "legalmente"
> valores no ASCII (acentos, etc), usa una codificacion iso-8859-1 o
> iso-8859-15. Usar SQL_ASCII es buscarse problemas en general.

Y si quiero usar codificacion mono-byte para un campo y usar
Unicode en otros campos me tendré que fastidiar claro.

> En todo caso, para Postgres los campos char(n), varchar(n) siempre tienen
> un numero variable de bytes. De hecho un char(4) usa un minimo de ocho
> bytes (los cuatro primeros indican el largo en bytes de lo que viene).
> Incluso char(1) usa minimo 5 bytes.
>
> Por eso recomiendo usar "char" con las comillas para almacenar un solo
> caracter. Eso te limita a no usar cosas multibyte y no lleva los 4
> bytes de largo al principio.

Pues precisamente el uso de "char" con comillas pone de manifiesto
una cosa. Un sistema de codificación no tiene porque afectar
necesariamente a todos los tipos que se basan en el uso de caracteres.

En Postgres por desgracia la codificación afecta a text, char(n),
varchar(n), y no se cuantas cosas más. No había necesidad de afectar
al tipo char(n). Yo creo que al usar codificacion multibyte tanto
para char(n), como para varchar(n) estamos desperdiciando la posibilidad
de respetar el tipo char(n) para campos de longitud fija. Yo creo que
el uso de char(n) y varchar(n) se convierte en la misma cosa cuando se
usa codificación multibyte. Si yo quiero usar un campo para codificar
artículos con cuatro caracteres los acentos y la eñes me sobran.

Si se hubiera dejado al marjen el tipo char(n) se podría elegir entre
char(n) y varchar(n) para cosas distintas. Es decir si alguien quiere
usar acentos y eñes podría recurrir a varchar(n) y si no quiere
usar acentos y le conviene codificar de manera eficiente unos indices de
tamaño fijo con cuatro caracteres podría usar el tipo char(4).

Quizás exista algo tipo "char (n)" entre comillas o similar y yo no
lo conozco. "char" está muy bien pero para campos de un solo byte.
Puede que exista solución al problema que planteo pero primero no
la conozco y segundo me parece un desperdicio que char(n) y varchar(n)
se comporten exactamente igual usando codificación multibyte.

--
Un saludo
Antonio Castro

/\ /\ Ciberdroide Informática
\\W// << http://www.ciberdroide.com >>
_|0 0|_
+-oOOO-(___o___)-OOOo---------------------+
| . . . . U U . Antonio Castro Snurmacher |
| . . . . . . . acastro(at)ciberdroide(dot)com |
+()()()---------()()()--------------------+