> Hola fernando, gracias por los datos y el tiempo que le dedicaste. Con
> respecto al modelo de datos es verdad que si hay distintos tipo es un
> error, lo solucinamos con los cast como vos decis. El tema era saber
> por que nos era mas lento con los indices varchar(42) que con los
> char(42). Igualmente nosotros seguimos con las pruebas veremos que
> resultados arrojan. Muchas Gracias
>
De hecho, ejecutá lo siguiente por cada tabla:
>> create table prueba_c( campo char(32) );
SELECT pg_relation_size('prueba_c');
>> create table prueba_v( campo varchar(32) );
SELECT pg_relation_size('prueba_v');
>> create table prueba_t( campo text );
SELECT pg_relation_size('prueba_t');
Lo que es inserciones no habrá problema. El tema que el tipo char al
ocupar más espacio en disco (en el caso que no se utilicen todos los
caracteres del string), habrá menos registros por bloque y por
consiguiente tendrá que leer estadísticamente más bloques para la
misma cantidad de conjunto de retorno. Esto se traduce a que
necesitará cachear más bloques (aún accediendo por índice, debe leer
el bloque).
Yo solo recomendaría char para casos específicos donde la lógica de
negocios te obligue a que se complete dicho valor (M o F es lo más
común).
--
Emanuel Calvo Franco
www.emanuelcalvofranco.com.ar
Join: http://www.thevenusproject.com/
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
