Re: migración y join de tablas

Hola soy fjpv_2000, estoy intentando hacer una migración de un sistema de base de datos a postgres (la migración ya la he hecho y todo funciona) pero me he encontrado con dos cositas que no se como resolverlas:
 
1) El ODBC no reconoce el parámetro LIMIT dentro de una select, me dice que no encuentra el token limit, lo he probado de muchas formas. ¿no está implemenetado?
 
2) El segundo problema es el que me trae más de cabeza. Es un problema de tiempo de respuesta cuando hago un join de dos tablas, me explico:
Tabla caberas(facturas) y Tabla detalles(facturas) hago una select de la siguiente forma:
 
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.
 
Es decir, los datos de las facturas de la oficina 841 el día 03/03/2008 son en total 3178 rows y me las devuelve en 72975 ms. Este tiempo es inaceptable para mis clientes.
He probado a construir la query de formas diferentes, crear un view y lanzarla sobre el view y nada el tiempo más o menos el mismo. Tengo índices sobre los campos que se usan en query, tengo restricción de clave ajena de detalles sobre cabecera.
El planing siempre me hace lo mismo:
* hash join (cost=179468.18 .. 194039.39 rows=1898 with=158)
  hash Cond: (detalles.id=cabecera.id)
* index scan using av2 on cabeceras (cost=0.00 .. 124.64 rows=454 with=104)
  index Cond: (fecha='2008-03-03'::date)
  filter: (cabecera.oficina=841)
* hash (cost=147263.31 .. 147263.31 rows=1446390 with=54)
     bitmap heap scan on detalles (cost=86772.43 .. 147263.31 rows=1446390 with=54)
     recheck Cond: (detalles.oficina=841)
 * bitmap index scan on  adv4 (cost=0.00..86410.84 rows=1446390 with=0)
   Index Cond:(detalles.oficina = 841)
 
Es decir, primero trata la tabla detalles (más grande) y después enlaza resultados con cabecera (pequeña). ¿Hay alguna forma de que trate la de cabeceras y con su resultado enlace con la de detalles? ya que si cada vez tiene que tratar así los resultados nunca serán optimos.
 
Comparativa de tiempos sistema actual (rbase) : 5 segundos y postgresql sobre el mismo equipo 72975 ms (DIFERENCIA BRUTAL).
 
Creo que he probado todas las combinaciones de work_mem, default_statistics, effective_cache ,... que he ido leyendo en Internet. ¿alguna sugerencia o ayuda?
saludos y gracias
 

-----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-----

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

Rafael Martinez wrote:

> 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.
>

Y se me olvido, mandanos el output de 'EXPLAIN ANALYZE <consulta>'
despues de hacer estos cambios.

- --
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)

iD8DBQFKu2VfBhuKQurGihQRArtMAJ0SH+xRmBnEyJ4VXIn8tTXL5GzH8QCeIMML
uXgm+qMKg0Kr2NpZWJmGxu8=
=kVDz
-----END PGP SIGNATURE-----

FRANCISCO JOSE PALAO VILLANUEVA escribió:
> Hola soy fjpv_2000, estoy intentando hacer una migración de un sistema de base de datos a postgres (la migración ya la he hecho y todo funciona) pero me he encontrado con dos cositas que no se como resolverlas:
>  
> 1) El ODBC no reconoce el parámetro LIMIT dentro de una select, me dice que no encuentra el token limit, lo he probado de muchas formas. ¿no está implemenetado?

Está implementado. ¿Cuál es la consulta que falla? ¿Probaste a
mandarla directamente en lugar de a través de ODBC?

--
Alvaro Herrera http://planet.postgresql.org/
"The important things in the world are problems with society that we don't
understand at all. The machines will become more complicated but they won't
be more complicated than the societies that run them." (Freeman Dyson)

Hola, gracias por la respuesta como siempre. Ya lo he resuelto y funciona ok.
Si lo había probado directamente, por eso te preguntaba si el problema era que no estaba implementado.
El problema es algún tipo de problema valga la redundancia entre el driver ODBC de postgresql y el componente TQuery de Delphi. Este tiene una propiedad llamada RequestLive, que permite pasar información al servidor desde el cliente, de forma que el TQuery trabaje en los dos sentidos, sino los resultados son sólo de lectura. Pues bien poniendo esta propiedad a True no reconoce el token limit, y además también falla cuando haces un join de tablas.¡que curioso el efecto!, si sólo haces una select simple funciona sin problemas.
Saludos

--- 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] 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 8:35

FRANCISCO JOSE PALAO VILLANUEVA escribió:
> Hola soy fjpv_2000, estoy intentando hacer una migración de un sistema de base de datos a postgres (la migración ya la he hecho y todo funciona) pero me he encontrado con dos cositas que no se como resolverlas:
>  
> 1) El ODBC no reconoce el parámetro LIMIT dentro de una select, me dice que no encuentra el token limit, lo he probado de muchas formas. ¿no está implemenetado?

Está implementado.  ¿Cuál es la consulta que falla?  ¿Probaste a
mandarla directamente en lugar de a través de ODBC?

--
Alvaro Herrera                               http://planet.postgresql.org/
"The important things in the world are problems with society that we don't
understand at all. The machines will become more complicated but they won't
be more complicated than the societies that run them."    (Freeman Dyson)
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
               http://archives.postgresql.org/pgsql-es-ayuda