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