Re: Crear los indices adecuados

From: Juan Martínez <jeugenio(at)umcervantes(dot)cl>
To: Miguel Bernilla Sánchez <mbernilla(at)sedapal(dot)com(dot)pe>
Cc: Vida Luz <vlal(at)ns(dot)ideay(dot)net(dot)ni>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Crear los indices adecuados
Date: 2007-03-23 15:26:32
Message-ID: 4603F1A8.9060206@umcervantes.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Miguel Bernilla Sánchez escribió:
> Con fecha Jueves, 22 de Marzo de 2007, 08:57:57 p.m., escribió:
>> Tengo una tabla con muchos campos, ademas que tiene como 3 millones de
>> registros, de esas tabla hay 16 campos
>> que se usaran de manera combinada para realizar consulta,

Con esas combinaciones deberias crear los indices, es decir, si filtras
por año y/o semestre, entonces:

CREATE INDEX tabla_ano_semestre ON tabla(ano,semestre);

>> como son
>> muchos query con distintas combinaciones y condicionales, en base al
>> ejemplo que les envio, quisiera una buena sugerencia para crear los
>> inidice y que la consulta sea liviana, en estos momentos mis tiempos
>> son muy altos, El caso es:

El hardware disponible? Es fundamental la cantidad de memoria y
ciertamente discos rapidos, pero aun mas lo es el tunning del sistema
operativo y de el mismo postgres... Espero que no tengan esa base
montada sobre Windows...

>> [Tabla con un severo mal diseño]

Tiene alguna justificación justificable para no tener como tipo de dato
en algunas columnas un integer? Claramente hay varias columnas que
pueden ser integer ahi.

> Existe alguna razón por la que todos los campos son "character"...?
> [...]
> Lo ideal es usar varchar.

Antes que des alguna opinion, interiorizate muy bien de lo que hablas.
En postgres character varying y varchar son lo mismo (de hecho este
ultimo es un alias del primero). Y disculpa si suena pesado lo que digo,
pero normalmente asi pueden comienzar algunos "mitos urbanos". Esto pasa
por no leer la documentacion afin[1].

>> Necesito consultar por ejemplo
>> Query 1
>> =======
>> SELECT V.geren_cod,V.geren_desc,V.ruta,V.ruta,V.cliente_cod,
>> V.cliente_desc,V.anio,V.anio,SUM(V.vta_cajas) as cajas,
>> SUM(V.vta_divisa) as divisa
>> FROM dm.venta V
>> WHERE V.anio IN(2007,2006,2005)
>> GROUP BY V.geren_cod,V.geren_desc,V.ruta,V.cliente_cod,V.cliente_desc,V.anio
>> ORDER BY V.geren_desc,V.geren_cod,V.ruta,V.cliente_desc,V.cliente_cod,
>> V.anio DESC

Sugeriria no usar el operador IN si tienes un dominio continuod de los
datos. En este caso sera mejor usar BETWEEN. Aca el indice esta claro,
uno solo por 'anio'.

El operador IN como debes saber equivale a un OR (alguna vez un profesor
de bases de datos de la universidad me dijo que a los motores (lease
optimizador) le es mas costozo usar un OR en una consulta a diferencia
que el AND, sera cierto en postgres?)

Solo un detalle. Definiste para la tabla venta el alias V. En postgres
si no usas comillas dobles en el alias, la uve mayuscula se transforma
en minusculas.

>> Query2
>> [...]

Igual para este query sirve el mismo indice.

>> Tengo la mas grande donde van casi todos los campos.

Uff...esto es lo mismo!
El costo de traer mas columnas de la tabla no debiera ser tan alto. El
costo va por los filtros (las clausulas de WHERE).

Creo que tu problema, ademas de crear indices, tiene que ver con un
rediseño de esa tabla (usar integer donde corresponda)

[1]http://www.postgresql.org/docs/current/static/datatype-character.html

--
Juan Martinez G. Mac Iver # 370
Departamento de Informatica 4997900 - 4997950
Universidad Miguel de Cervantes Santiago - Chile
http://download.bblug.usla.org.ar/netiquette.png

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Espartano 2007-03-23 15:35:18 Re: Guardar y recuperar imagenes
Previous Message Leonel 2007-03-23 15:24:13 Re: Configurar usuario postgres