Re: Busqueda de duplicados, con demora. SOLUCION

Gracias por tu aporte, retocando una coma funciono a
la perfeccion, igualmente probe en access y con mssql
esta solucion y obtengo casi igual velocidad de
respuesta que con la primera propuesta, mientras que
en postgresql solo camina esta ultima solucion.
Muestro el sql que funciona en postgresql, en access y
en mssql con una demora de 6 sec aprox, el explain y
la original que no funciona en postgresql pero que
funciona en access en 5 sec aprox.

Esto me da una idea para documentar sobre distintos
planteos que usando una u otra herramienta, aunque
sean sql, deben hacerse distintos para obtener mayor
rendimiento en uno u otro ordbms.

Aca muestro la sentencia final de 6 sec.

SELECT
dups.id_articulo,
dups.id_proveedor,
det.id_en_proveedor,
det.dto1,
det.dto2,
det.unidades_x_envase,
det.id_imagen
FROM
(select ap.id_articulo, ap.id_proveedor
from central.articulo_proveedor as ap
group by ap.id_articulo, ap.id_proveedor
having count(*) > 1
) as dups
LEFT JOIN central.articulo_proveedor as det
ON
dups.id_articulo = det.id_articulo
and dups.id_proveedor = det.id_proveedor

QUERY PLAN

-----------------------------------------------------------------------------------------------------------------------------------------------------------
Hash Left Join (cost=3071.35..13855.53 rows=62334
width=102) (actual time=781.837..883.107 rows=18
loops=1)
Hash Cond: (((dups.id_articulo)::text =
(det.id_articulo)::text) AND (dups.id_proveedor =
det.id_proveedor))
-> GroupAggregate (cost=0.00..6589.37 rows=62334
width=21) (actual time=240.249..427.019 rows=9
loops=1)
Filter: (count(*) > 1)
-> Index Scan using idartprov on
articulo_proveedor ap (cost=0.00..5186.85 rows=62334
width=21) (actual time=0.063..185.583 rows=62334
loops=1)
-> Hash (cost=1222.34..1222.34 rows=62334
width=86) (actual time=391.223..391.223 rows=62334
loops=1)
-> Seq Scan on articulo_proveedor det
(cost=0.00..1222.34 rows=62334 width=86) (actual
time=0.036..165.207 rows=62334 loops=1)
Total runtime: 883.713 ms
(8 filas)

----------------------------------------------
La consulta planteada al principio 5 sec, no resuelta
en postresql

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 articulo_proveedor.id_articulo,
articulo_proveedor.id_proveedor;

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.

Mi conclusion, postgresql es mejor herramienta sin
duda que las propuestas por MS, pero uno debe alejar
su cabeza de los esquemas planteados para usar una si
quiere rendir mejor en la otra.

A parte de aprender a participar en el foro para
recibir el valioso aporte que este tiene, la verdad
que pasarse a postgresql es flor de experiencia para
abrir la mente.

Atte.
Gabriel Hermes Colina Zambra

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