Re: Distintos planes de ejecución

Alejandro D. Burne escribió:
> Tengo la siguiente consulta:
>
> select * from afiliadospadrones where nombreafiliado like 'BURNE%'
>
> en un servidor corriendo 8.1.1 me tira el siquiente plan
>
> Index Scan using ixap_nombreafiliado on afiliadospadrones
> (cost=0.00..5.97 rows=1 width=171) (actual time=0.045..0.138 rows=23
> loops=1)
> Index Cond: (((nombreafiliado)::text >= 'BURNE'::character varying)
> AND ((nombreafiliado)::text < 'BURNF'::character varying))
> Filter: ((nombreafiliado)::text ~~ 'BURNE%'::text)
> Total runtime: 0.224 ms
>
> la misma consulta en otro corriento 8.2 (donde levanté un backup de la
> anterior, analyze mediante):
>
> Sort (cost=46084.92..46085.20 rows=113 width=170) (actual
> time=7047.705..7047.754 rows=21 loops=1)
> Sort Key: nombreafiliado
> -> Seq Scan on afiliadospadrones (cost=0.00..46081.06 rows=113
> width=170) (actual time=574.000..7042.618 rows=21 loops=1)
> Filter: ((nombreafiliado)::text ~~ 'BURNE%'::text)
> Total runtime: 7048.063 ms
>
> Me llama la atención cómo la primera arma la condición de filtro y
> permite utilizar el índice respecto de la segunda, alguna pista?

Lo mas probable es que en 8.1 tengas locale=C y en 8.2 tengas otro. O
bien que el indice en 8.1 sea varchar_pattern_ops y el de 8.2 no lo sea.

En cualquier caso, probablemente la mejor solucion sea crear un indice
con varchar_pattern_ops en el servidor con 8.2.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support