From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Sebastian Machuca <serroba(at)gmail(dot)com> |
Cc: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: El indice no mejora me mejora el rendimiento de mis consultas. |
Date: | 2009-08-27 16:21:59 |
Message-ID: | 20090827162159.GI11213@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Sebastian Machuca escribió:
> SET enable_indexscan TO OFF;
> SET
>
> EXPLAIN ANALYZE SELECT ani from trx_8 group by ani;
> QUERY PLAN
> --------------------------------------------------------------------------------------------------------------------
> HashAggregate (cost=8668.54..8668.56 rows=2 width=8) (actual
> time=1658.423..1658.427 rows=2 loops=1)
> -> Seq Scan on trx_8 (cost=0.00..7778.83 rows=355883 width=8) (actual
> time=0.011..728.418 rows=355883 loops=1)
> Total runtime: 1658.680 ms
> (3 rows)
>
>
> No veo diferencia.
Hay mucha -- en este hace un seqscan + hashaggregate en vez de un
indexscan+unique que hacía en el plan que pusiste la primera vez. En
total esto seguramente tiene menor costo porque hay menos I/O aleatorio.
Pero todo esto es en realidad una pérdida de tiempo, porque cuando
quieras ejecutarlo sobre la tabla de 3M registros en vez de esta tabla
de juguete, cualquiera de los dos planes va a ser igualmente inaceptable
por lento. Creo que debes replantear el diseño si de verdad necesitas
la respuesta que entrega esta consulta; cosa que no me queda totalmente
clara que así sea.
--
Alvaro Herrera http://planet.postgresql.org/
"No me acuerdo, pero no es cierto. No es cierto, y si fuera cierto,
no me acuerdo." (Augusto Pinochet a una corte de justicia)
From | Date | Subject | |
---|---|---|---|
Next Message | Rafael Martinez | 2009-08-27 16:40:08 | Re: documentacion Pgpool II |
Previous Message | Sebastian Machuca | 2009-08-27 15:30:18 | Re: El indice no mejora me mejora el rendimiento de mis consultas. |