From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | 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 |
Subject: | Re: Re: [pgsql-es-ayuda] migración y join de tablas |
Date: | 2009-09-25 16:08:21 |
Message-ID: | 20090925160821.GN3914@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
FRANCISCO JOSE PALAO VILLANUEVA escribió:
> 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.
Doh.
> 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.
No. Lamentablemente esa es la forma más eficiente para implementar esta
consulta por el momento. Si realmente necesitas resolver esa consulta
de forma eficiente, creo que tendrías que rediseñar tu modelo de alguna
forma.
--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
"No hay ausente sin culpa ni presente sin disculpa" (Prov. francés)
From | Date | Subject | |
---|---|---|---|
Next Message | FRANCISCO JOSE PALAO VILLANUEVA | 2009-09-25 18:22:11 | Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] migración y join de tablas |
Previous Message | Alvaro Herrera | 2009-09-25 16:03:59 | Re: Dos instancias de PostgreSQL conviviendo en un mismo PG_DATA |