Re: Busqueda de duplicados, con demora. 3 SOLUCIONES OK

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. 3 SOLUCIONES OK
Date: 2007-06-05 16:43:34
Message-ID: 809992.93785.qm@web63702.mail.re1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Alvaro tu solucion funciono en los dos casos asi que
ahora tenemos 3 soluciones. Te pido disculpas por el
hecho de que los datos de prueba cuando ejecute la
primera opcion, no eran los correctos, o sean los que
tenian el problema, la probe con un juego de datos sin
duplicados. Casi me cayo esto por que ahora que estoy
con los datos reales, probe las tres opciones,

La opcion primaria que me habias planteado
me da 260 ms , la segunda opcion 421 mientras que la
tercera la del join 471

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

> Gabriel Hermes Colina Zambra escribió:
>
> > --- Alvaro Herrera <alvherre(at)commandprompt(dot)com>
> > escribió:
>
> > > 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)
> > > ORDER BY id_articulo, id_proveedor;
>
> Ahh, ya entiendo lo que pasa. La query que te pasé
> obtiene los
> id_articulo de los registros que aparecen duplicados
> segun el par
> (id_articulo, id_proveedor), y luego obtiene todos
> los articulos con
> cada uno de esos id_articulo, ignorando el
> id_proveedor.
>
Que funciona, solo que pido disculpas los datos de
prueba que tenia en el trabajo ya tenia los depurados,
mientras que en casa todavia los conservaba y lo
probe.


> Prueba esto otro:
>
> 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
> FROM central.articulo_proveedor
> WHERE (central.articulo_proveedor.id_articulo,
> central.articulo_proveedor.id_proveedor) In
> (SELECT id_articulo, id_proveedor
> FROM central.articulo_proveedor As Tmp
> GROUP BY id_articulo, id_proveedor
> HAVING Count(*)>1)
> ORDER BY id_articulo, id_proveedor;
>
>
> Observa que el HAVING de la subconsulta es mas
> simple (no necesitar
> poner la condicion que lo liga a la tabla de la
> consulta externa), pero
> el IN compara ahora dos columnas, no solo una; y los
> resultados que
> entrega deberian ser los duplicados que te
> interesan. (Observa que le
> quite la clausula INTO para poder hacer pruebas mas
> comodamente).

Esto es un bolido en un servidor windows con un
hardware lamentable, es muy buena propuesta.

>
> Aca hice lo siguiente para experimentar:
>
> create schema central;
> create table central.articulo_proveedor (id_articulo
> int, id_proveedor int,
> id_en_proveedor int, dto1 int, dto2 int,
> unidades_x_envase int,
> id_imagen bytea);
>
> insert into central.articulo_proveedor (id_articulo,
> id_proveedor)
> select * from generate_series(1, 1000) a,
> generate_series (1, 40) b
> where a % 4 = b % 5 ;
>
> insert into central.articulo_proveedor (id_articulo,
> id_proveedor)
> select * from generate_series(1, 1000) a,
> generate_series (1, 40) b
> where a % 4 = b % 5 and a % 3 = b % 7 limit 10;
>
> analyze central.articulo_proveedor ;
>
>
>
Esto lo voy a guardar para la historia.

> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom
> Development, 24x7 support
>
> ---------------------------(fin del
> mensaje)---------------------------
> TIP 10: visita nuestro canal de IRC #postgresql-es
> en irc.freenode.net
>
La tercera opicon
select
sqlres.id_articulo,sqlres.id_proveedor,sqlres.id_en_proveedor
,rdup.instancia from
(
select id_articulo,id_proveedor,count(*) as instancia
from central.articulo_proveedor
group by
id_articulo,id_proveedor
having count(*)>1 ) as rdup
left join central.articulo_proveedor as sqlres
on sqlres.id_articulo = rdup.id_articulo

Tambien tiene buen desempeño.

Ahora si todas funcionan en cualquiera de las
plataformas, pero con las modificaciones del caso,
postgresql logra mejor performance que la ejecucion de
las mismas en MSSQL y por supuesto mucho mayor que en
Access.

Agradezco a Alvaro y a Osvaldo por la paciencia, por
que aunque mi necesidad estuviera resuelta, no estaban
resueltas algunas incognitas y con esto se reafirmo
aun mas la teoria de que en postgresql cualquiera que
migre va a tener como mayor ventaja una excelente
herramienta. la condicion, no ser perezoso, leer,
hacer laboratorio y preguntar.

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

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Gunnar Wolf 2007-06-05 16:45:22 Re: Conversion de tablas .dbf a postgresql
Previous Message Mario Gonzalez 2007-06-05 16:29:22 Re: Conversion de tablas .dbf a postgresql