Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-es-ayuda by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group