--- El jue, 24/9/09, FRANCISCO JOSE PALAO VILLANUEVA <[email protected]> 
escribió:


De: FRANCISCO JOSE PALAO VILLANUEVA <[email protected]>
Asunto: Re: [pgsql-es-ayuda] migración y join de tablas
Para: "Rafael Martinez" <[email protected]>
Fecha: jueves, 24 septiembre, 2009 5:15







Hola, ante todo gracias por la rápida respuesta, voy a tratar de responder a 
todo:
 
versión 8.4.1 de postgresql sobre windows xp profesional sp 2.
 
cabecera tiene: 25 columnas y 669785 filas.
detalles tiene  : 13 columnas y 3772530 filas.
 
El join que propones responde en el mismo tiempo más o menos.
 
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
 
     ES UNA BARBARIDAD para el número de filas que devuelve.
 
Como ves todo igual, sigo pensando que el planner se equivoca de cabo a rabo, 
la consulta sólo sobre cabeceras devuelve 381 rows en 51ms, debería usar esto 
junto con la relación de integridad (clave ajena) definida sobre detalles y 
obtener el resultado final. Sería muchísimo más eficiente y la clave la tiene 
en las narices número de rows de cada tabla y la constraint de clave ajena.
 
gracias.

--- El jue, 24/9/09, Rafael Martinez <[email protected]> escribió:


De: Rafael Martinez <[email protected]>
Asunto: Re: [pgsql-es-ayuda] migración y join de tablas
Para: "FRANCISCO JOSE PALAO VILLANUEVA" <[email protected]>
CC: [email protected]
Fecha: jueves, 24 septiembre, 2009 2:23


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FRANCISCO JOSE PALAO VILLANUEVA wrote:

>  
> select cabecera.*,detalles.* from cabecera,detalles where
> cabecera.id=detalles.id and cabecera.oficina=detalles.oficina and
> cabecera_fecha='03/03/2008' and cabecera.oficina=841.
>  

Hola

Lo que se puede ver a primera vista en el planner es que el numero de
tuplas que tu dices devuelve no tiene nada que ver con las que el
planner cree que existen.

- - Que version de Postgresql estas utilizando?
- - Cuantas columnas tienen las tablas cabeceras y detalles?
- - Nos podrias dar la definicion de las tablas cabeceras y detalles?
\d cabeceras
\d detalles

Te doy una lista de cosas que yo comprobaria:

1) Yo reescribiria la consulta asi (aunque no deberia de influenciar en
el resultado):

SELECT a.*,b.*
FROM cabecera a
INNER JOIN detalles b ON(a.id=b.id AND a.oficina=b.oficina)
WHERE a.fecha='03/03/2008'
AND a.oficina=841;

- - Que valor tienes en el parametro default_statistics?¿Puedes probar con
el valor 100?
- - Has ejecutado 'VACUUM VERBOSE ANALYZE' o 'ANALYZE VERBOSE' despues de
cambiar default_statistics? Esto es muy importante.

Ya contaras ....
- --
Rafael Martinez, <[email protected]>
Center for Information Technology Services
University of Oslo, Norway

PGP Public Key: http://folk.uio.no/rafael/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFKu2TABhuKQurGihQRAleSAJwLxNilBr7OhxBnFm89ZO4RyTOSZwCeKzgP
+45/XnbyTDJ+V6E24n+Ateo=
=pEYo
-----END PGP SIGNATURE-----




      

Responder a