Re: ayuda con planeador

Cristian, como indica Alvaro, parece difícil creer que normalizado no funcione bien.

En otro post hacian referencia a utilizar la clausula INNER JOIN en las consultas, que mejorar el rendimiento.

Con la No normalizada también se me ocurre lo siguiente:
Crear 5 indices 1 por cada (id | catx_id)
y luego hacer una 5 consultas unidas con UNION

Ejemplo (al vuelo)
select campo1, campo2 from tabla where id=x and cat1_id=y
union all
select campo1, campo2 from tabla where id=x and cat2_id=y
union all
select campo1, campo2 from tabla where id=x and cat3_id=y
union all
select campo1, campo2 from tabla where id=x and cat41_id=y
union all
select campo1, campo2 from tabla where id=x and cat5_id=y

Pablo.

----- Original Message ----
From: Cristian Saavedra <cristian(dot)aquii(at)gmail(dot)com>
To: Cristian Saavedra <cristian(dot)aquii(at)gmail(dot)com>; pgsql-es-ayuda(at)postgresql(dot)org
Sent: Wednesday, January 10, 2007 6:45:59 PM
Subject: Re: [pgsql-es-ayuda] ayuda con planeador

On 1/10/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Cristian Saavedra escribió:
> > On 1/10/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> > >Cristian Saavedra escribió:
> > >
> > >Hola,
> > >
> > >> Tengo una pregunta, tengo una tabla con varios datos sobre compañias,
> > >> esta tabla tiene casi 10'000.000 de registros. Ahora, hay un campo que
> > >> es la llave primaria y otros 6 campos que referencian todos a la misma
> > >> tabla.
> > >>
> > >> id | cat1_id | cat2_id | cat3_id | cat4_id | cat5_id | varios
> > >campos.......
> > >>
> > >-------------------------------------------------------------------------------------------
> > >
> > >Huh, el modelo es un poco sucio -- por que no poner esos ID de categoria
> > >en una tabla aparte? Cuentanos, esas columnas son no nulas?
> > >
> > Jejeje tienes razon en lo de lo sucio del modelo, inicialmente se
> > encontraban en una tabla intermedia que permitia tener una relacion de
> > 1 a N, pero pues eso ocasiona el tener tablas muy grandes y en el
> > momento de hacer la busqueda el servidor no podia con el join de esa
> > tabla. Asi que como la informacion quien nos la suministra, garantiza
> > que no tiene mas de 5 campos, entonces decidi irme por ese lado
> > buscando esta vez velocidad (que es lo mas importante en este caso) en
> > lugar de normalizacion de los datos.
>
> El servidor no se la podia? Me parece dudoso. Te sugiero que pruebes
> volviendo a normalizar, y luego nos muestres un EXPLAIN ANALYZE de la
> consulta que trae los datos que te interesan, a ver que te podemos
> aconsejar.
>

Si claro, estoy creando unos indices sobre la tabla que me presenta el
problema, en cuanto termine ejecuto los dos querys, el normalizado y
el otro y los traigo por aca.

---------------------------(fin del mensaje)---------------------------
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envíe "unregister TuDirecciónDeCorreo" a majordomo(at)postgresql(dot)org)

__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas