Skip site navigation (1) Skip section navigation (2)

Re: optimizar consulta

From: Gabriel Ferro <gabrielrferro(at)yahoo(dot)com(dot)ar>
To: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: optimizar consulta
Date: 2009-03-28 20:24:32
Message-ID: 276277.53610.qm@web52105.mail.re2.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
> pregunta con esta parte....
> (padrones.personas.clave in (select * from
> padrones.buscarexacta_persona('PIRULO ESTEBAN',''))
> esto funciona..?¿ no deberia de devolverte un error el in porque el
> subquery retorna mas de una columna?¿
> 

retorna solo una, justamente la funcion es del tipo
                    CREATE TYPE respuesta_buscar_persona AS   (clave bigint);
lo que pasa es que en realidad la funcion busca dos valores en dos campos (por eso esos apstrofos vacios despues del nombre), solo que no lo puse aqui para que no quede complicado.

> segundo ese tipo de like %% son inadecuados dado que no utiliza el
> indice si es que tienes creado uno sobre esa columna...

lo se.. en realidad el usuario tiene un combo con todas las localidades cargadas, pero se le permite escribir lo que quiera por si se embarulla con tantas localidades (solo en este ultimo caso se usa ese like, sino se usa directamente la clave de la localidad), de todas maneras hice una funcion de busqueda similar a la de busqueda de personas con tsvector y mejoro un par de milisegundos, asi que hice
SELECT * FROM padrones.personas 
WHERE (padrones.personas.clave in (select * from padrones.buscarexacta_persona('JUAN TRONCOSO',''))) 

y me dio Total query runtime: 8218 ms.77 rows retrieved.
DEDUCCION1: la funcion no es la del problema

Si hago

SELECT padrones.personas.numdoc, padrones.personas.nombre, padrones.personas.otrosnombres,padrones.personas.datos, padrones.personas.sexo, 
padrones.personas.fechanac, padrones.docu.tipo AS TDOC, padrones.localidades.nombreloc, padrones.personaloc.direccion 
From padrones.personas 
INNER JOIN padrones.docu ON (padrones.personas.tipodoc=padrones.docu.clave) 
INNER JOIN padrones.personaloc ON (padrones.personas.clave=padrones.personaloc.claveper) 
INNER JOIN padrones.localidades ON (padrones.personaloc.claveloc=padrones.localidades.claveloc) 
WHERE (padrones.personas.clave in (select * from padrones.buscarexacta_persona('JOSE TRONQUITO','')) 
 and (padrones.localidades.claveloc in (select * from padrones.buscar_localidad('PARANA')))) 

Me da Total query runtime: 67515 ms. 1 rows retrieved.

BUEEE.. parece que era el maldito like, cosa rara porque las localidades no son demasiadas. de todas maneras les mando un explain analyze

EXPLAIN ANALYZE SELECT padrones.personas.numdoc, padrones.personas.nombre, padrones.personas.otrosnombres,padrones.personas.datos, padrones.personas.sexo, 
padrones.personas.fechanac, padrones.docu.tipo AS TDOC, padrones.localidades.nombreloc, padrones.personaloc.direccion 
From padrones.personas 
INNER JOIN padrones.docu ON (padrones.personas.tipodoc=padrones.docu.clave) 
INNER JOIN padrones.personaloc ON (padrones.personas.clave=padrones.personaloc.claveper) 
INNER JOIN padrones.localidades ON (padrones.personaloc.claveloc=padrones.localidades.claveloc) 
WHERE (padrones.personas.clave in (select * from padrones.buscarexacta_persona('FERRO RAMIRO','')) 
 and (padrones.localidades.claveloc in (select * from padrones.buscar_localidad('PARANA')))) 

"Hash Join  (cost=529.40..668084.32 rows=45 width=622) (actual time=31537.615..119985.027 rows=1 loops=1)"
"  Hash Cond: (personas.tipodoc = docu.clave)"
"  ->  Nested Loop  (cost=528.00..668082.30 rows=45 width=620) (actual time=31525.049..119972.457 rows=1 loops=1)"
"        ->  Nested Loop IN Join  (cost=528.00..667142.50 rows=61 width=59) (actual time=31457.125..119904.523 rows=1 loops=1)"
"              Join Filter: (personaloc.claveloc = buscar_localidad.clave)"
"              ->  Nested Loop  (cost=267.00..665987.36 rows=200 width=67) (actual time=12218.371..119845.117 rows=4 loops=1)"
"                    ->  Hash Join  (cost=267.00..664376.01 rows=200 width=31) (actual time=12155.078..119702.108 rows=4 loops=1)"
"                          Hash Cond: (personaloc.claveper = buscarexacta_persona.clave)"
"                          ->  Seq Scan on personaloc  (cost=0.00..590170.10 rows=19716510 width=23) (actual time=0.020..76586.971 rows=19716510 loops=1)"
"                          ->  Hash  (cost=264.50..264.50 rows=200 width=8) (actual time=1127.507..1127.507 rows=4 loops=1)"
"                                ->  HashAggregate  (cost=262.50..264.50 rows=200 width=8) (actual time=1127.482..1127.492 rows=4 loops=1)"
"                                      ->  Function Scan on buscarexacta_persona  (cost=0.00..260.00 rows=1000 width=8) (actual time=1127.444..1127.451 rows=4 loops=1)"
"                    ->  Index Scan using localidades_pkey on localidades  (cost=0.00..8.04 rows=1 width=36) (actual time=35.733..35.737 rows=1 loops=4)"
"                          Index Cond: (localidades.claveloc = personaloc.claveloc)"
"              ->  Materialize  (cost=261.00..271.00 rows=1000 width=8) (actual time=14.611..14.751 rows=46 loops=4)"
"                    ->  Function Scan on buscar_localidad  (cost=0.00..260.00 rows=1000 width=8) (actual time=58.426..58.532 rows=59 loops=1)"
"        ->  Index Scan using personas_pkey on personas  (cost=0.00..15.39 rows=1 width=577) (actual time=67.913..67.917 rows=1 loops=1)"
"              Index Cond: (personas.clave = personaloc.claveper)"
"  ->  Hash  (cost=1.18..1.18 rows=18 width=8) (actual time=12.545..12.545 rows=18 loops=1)"
"        ->  Seq Scan on docu  (cost=0.00..1.18 rows=18 width=8) (actual time=12.456..12.493 rows=18 loops=1)"
"Total runtime: 119985.179 ms"


      Yahoo! Cocina
Recetas prácticas y comida saludable
http://ar.mujer.yahoo.com/cocina/

In response to

Responses

pgsql-es-ayuda by date

Next:From: Jaime CasanovaDate: 2009-03-28 21:10:21
Subject: Re: optimizar consulta
Previous:From: Luis GranadosDate: 2009-03-28 18:49:04
Subject: Baja de la Lista

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group