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

Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] migración y join de tablas

From: FRANCISCO JOSE PALAO VILLANUEVA <fjpv_2000(at)yahoo(dot)es>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: pgsql-es-ayuda(at)postgresql(dot)org, r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no
Subject: Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] migración y join de tablas
Date: 2009-09-25 11:21:11
Message-ID: 122838.16979.qm@web24107.mail.ird.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Hola,
gracias solucionado el tema era el parámetro enable_nestloop, ahora la misma join le cuesta entre 851ms y 1125ms, ahora si que si.
 
Otra cuestión:
Si hago un select distinc(oficina) from cabeceras, es decir, me diga las diferentes oficinas que hay en esta tabla (669785 filas) hace:
Unique (cost=0.00 .. 208525.76 rows=10 with=2)
-> index scan using av3 (indice oficina) on cabeceras (cost=0.00 .. 206851.29 rows=669785 with=2)
 
O sea, hace un scan de la tabla usando el índice (todo correcto), pero le cuesta 16353ms para devolver 10 oficinas diferentes. ¿Esto no muy es exagerado en tiempo? en mi base de datos actual le cuesta 3 o 4 segundos.
 
Saludos y gracias

--- El jue, 24/9/09, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> escribió:


De: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Asunto: Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] migración y join de tablas
Para: "FRANCISCO JOSE PALAO VILLANUEVA" <fjpv_2000(at)yahoo(dot)es>
CC: pgsql-es-ayuda(at)postgresql(dot)org, r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no
Fecha: jueves, 24 septiembre, 2009 9:33


FRANCISCO JOSE PALAO VILLANUEVA escribió:

> La variable default_statistisc_target ya la tenía a 100. He vuelto a hacer un 'VACUUM VERBOSE ANALYZE por si acaso. El resultado del explain analyze sobre la consulta es el siguiente (ahora he puesto 03/03/2009 en vez de 03/03/2008), pero es lo mismo:
>  
> Los indices adv4 sobre detalles.oficina y el av2 sobre cabecera.fecha
>  
> Hash Join (cost=179735.16 .. 194428.12 rows=1970 with=158)(actual time=69224.013 .. 76369.415 rows=1896 loops=1)
>  hash Cond:(t1.id=t2.id)
> -->Index Scan using av2 on cabecera t1 (cost=0.00 .. 153.63 rows=481 with 104)(actual time=0.463..2.849 rows=331 loops=1)
>    Index Cond:(t1.fecha='2009-03-03'::date)
>    Filter: (t1.oficina=841)
> -->Hash (cost=147359.20 .. 147359.20 rows=1454077 with=54)(actual time=69222.536..69222.536 rows=1457123 loops=1)
>   --> Bitmap Heap Scan on detalles t2 (cost=86772.23..147359.20 rows=1454077 with=54)(actual time=7813.689 .. 65958.794 rows=1457123 loops=1)
>    Recheck Cond:(t1.oficina=841)
>    -->Bitmap Index Scan on adv4 (cost=0.00 .. 86408.71 rows=1454077 with=0)(actual time= 7785.337 .. 7785.337 rows=1457123 loops=1)
>      Index Cond:(t1.oficina=841)
>  
> total runtime=76374.525ms

¿Tienes un índice en cabecera.oficina?

¿Tienes algún parámetro del planner en off?  enable_seqscan,
enable_nestloop, enable_mergejoin o alguno de esos.

No hay ninguna estimación que se vea obviamente equivocada en el plan.

Por favor no copies a mano el explain en el email; copia y pega
directamente desde el terminal que ejecuta el explain.

-- 
Alvaro Herrera                 http://www.amazon.com/gp/registry/CTMLCN8V17R4
"Ciencias políticas es la ciencia de entender por qué
los políticos actúan como lo hacen"  (netfunny.com)
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
    (envía "unregister TuDirecciónDeCorreo" a majordomo(at)postgresql(dot)org)



      

In response to

Responses

pgsql-es-ayuda by date

Next:From: iescrivaDate: 2009-09-25 12:30:34
Subject: Re: Tablespaces llenos ¿es posible?
Previous:From: iescrivaDate: 2009-09-25 09:23:48
Subject: Re: Tablespaces llenos ¿es posible?

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