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

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

From: FRANCISCO JOSE PALAO VILLANUEVA <fjpv_2000(at)yahoo(dot)es>
To: pgsql-es-ayuda(at)postgresql(dot)org
Cc: r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no
Subject: Re: [pgsql-es-ayuda] migración y join de tablas
Date: 2009-09-24 16:03:10
Message-ID: 400750.68453.qm@web24108.mail.ird.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda

--- El jue, 24/9/09, FRANCISCO JOSE PALAO VILLANUEVA <fjpv_2000(at)yahoo(dot)es> escribió:


De: FRANCISCO JOSE PALAO VILLANUEVA <fjpv_2000(at)yahoo(dot)es>
Asunto: Re: [pgsql-es-ayuda] migración y join de tablas
Para: "Rafael Martinez" <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
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 <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> escribió:


De: Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Asunto: 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
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, <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
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-----




      

Responses

pgsql-es-ayuda by date

Next:From: Marcos Luis Ortiz ValmasedaDate: 2009-09-24 16:19:38
Subject: Dos instancias de PostgreSQL conviviendo en un mismo PG_DATA
Previous:From: Ana SmailDate: 2009-09-24 12:49:11
Subject: pgdump

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