Re: Distintos planes de ejecución

El 30/01/07, Alvaro Herrera<alvherre(at)commandprompt(dot)com> escribió:
> 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
>

Gracias Alvaro por la respuesta, efectivamente había utilizado
varchar_pattern_ops en los índices oportunamente y no lo recordaba.
Mis disculpas....

Alejandro