Re: Busqueda de duplicados, con demora. SOLUCION

From: Gabriel Hermes Colina Zambra <hermeszambra(at)yahoo(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Oswaldo Hernández <listas(at)soft-com(dot)es>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Busqueda de duplicados, con demora. SOLUCION
Date: 2007-06-03 22:52:29
Message-ID: 619432.74194.qm@web63710.mail.re1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda


--- Alvaro Herrera <alvherre(at)commandprompt(dot)com>
escribió:

> Gabriel Hermes Colina Zambra escribió:
>
> > Este es el tercer caso en que tengo que variar el
> > planteo de sql, para que funcione mejor en
> postgresql,
> > en este caso para que funcione, y tengo ganas de
> > empezar a documentar estos casos para la gente que
> > como yo estamos migrando y a veces por
> desconocimiento
> > podemos sacar concluciones rapidas sobre
> performance,
> > sin variar los planteos.
>
> Tengo la impresion de que el comportamiento de las
> otras dos
> herramientas viola la interpretacion correcta de la
> sentencia.
> Puesto que deberia haber un producto cartesiano de
> la tabla consigo
> misma. Si te devuelve un numero razonable de
> registros entonces la
> respuesta que ellos te estan dando esta mala.
>
> --
> Alvaro Herrera Valdivia, Chile ICBM: S 39º
> 49' 18.1", W 73º 13' 56.4"
> "El destino baraja y nosotros jugamos" (A.
> Schopenhauer)
>
Si Alvaro, el total de registros es 18 o sea 9
duplicados, en los dos casos.
La verdad es que no se como lo hace internamente pero
lo resuelven bien, de todas maneras me quedo con la
solucion del left join que funciona en todas.

Si de algo te sirve te tiro el explain de la consulta
que en PostgreSql no camina, lamento mucho mi
ignorancia para interpretarlo para sacar conclusiones
utiles.

explain
SELECT central.articulo_proveedor.id_articulo,
central.articulo_proveedor.id_proveedor,
central.articulo_proveedor.id_en_proveedor,
central.articulo_proveedor.dto1,
central.articulo_proveedor.dto2,
central.articulo_proveedor.unidades_x_envase,
central.articulo_proveedor.id_imagen INTO dupartprov
FROM central.articulo_proveedor
WHERE central.articulo_proveedor.id_articulo In
(SELECT id_articulo FROM central.articulo_proveedor As
Tmp GROUP BY id_articulo,id_proveedor HAVING
Count(*)>1 And id_proveedor =
central.articulo_proveedor.id_proveedor)
ORDER BY id_articulo, id_proveedor;

Resultado

QUERY PLAN

------------------------------------------------------------------------------------------------
Index Scan using idartprov on articulo_proveedor
(cost=0.00..94932622.53 rows=31167 width=86)
Filter: (subplan)
SubPlan
-> HashAggregate (cost=1444.96..1578.54
rows=8905 width=21)
Filter: (count(*) > 1)
-> Seq Scan on articulo_proveedor tmp
(cost=0.00..1378.18 rows=8905 width=21)
Filter: (id_proveedor = $0)
(7 filas)

Gracias una ves mas por tu respuesta

Atte
Gabriel Hermes Colina Zambra

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Gabriel Hermes Colina Zambra 2007-06-03 23:01:51 Re: Re[2]: Consulta con fechas
Previous Message Ever Daniel Barreto Rojas 2007-06-03 22:28:05 Re[2]: Consulta con fechas