Re: tipo de datos

From: Emanuel Calvo Franco <postgres(dot)arg(at)gmail(dot)com>
To: Agustin Ignacio Genoves <agustingenoves(at)gmail(dot)com>
Cc: Fernando Hevia <fhevia(at)ip-tel(dot)com(dot)ar>, POSTGRES <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: tipo de datos
Date: 2010-06-18 16:38:28
Message-ID: AANLkTik0dqwmL7-7Ts7plzbbls_vUNYnmG1xAnarV9Xq@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

> 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/

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Juan José Rosales 2010-06-18 17:50:39 Re: tipo de datos
Previous Message Emanuel Calvo Franco 2010-06-18 16:30:01 Re: una bd con varios esquemas o varias bd