Re: velocidad en consulta con like

hola a todos

estoy buscando mejorar el tiempo de una consulta sql que actualmente
lleva entre 3000 y 5000 ms, entiendo que es un tiempo razonable,
pero me gustaría saber si habría alguna posibilidad de mejorarlo aún
más

// PostgreSQL 8.2.3 en una PC con WindowsXP

la consulta que estoy realizando es esta:
SELECT *
FROM vw_personas
WHERE per_nombres LIKE 'EVER D%' AND per_apellidos LIKE 'BARRET%'

sobre una tabla con 4.140.619 registros, el explain analyze de la
consulta es esta:
"Sort (cost=138124.45..138124.46 rows=1 width=2252) (actual time=3770.737..3770.740 rows=1 loops=1)"
" Sort Key: persona.per_apellidos, persona.per_nombres"
" -> Nested Loop (cost=0.00..138124.44 rows=1 width=2252) (actual time=2663.531..3770.693 rows=1 loops=1)"
" Join Filter: (persona.idecivil = ec.idecivil)"
" -> Nested Loop (cost=0.00..138123.35 rows=1 width=2239) (actual time=2663.484..3770.631 rows=1 loops=1)"
" Join Filter: (persona.idtdoc = td.idtdoc)"
" -> Seq Scan on persona (cost=0.00..138122.29 rows=1 width=2203) (actual time=2663.411..3770.548 rows=1 loops=1)"
" Filter: (((per_nombres)::text ~~ 'EVER D%'::text) AND ((per_apellidos)::text ~~ 'BARRET%'::text))"
" -> Seq Scan on tipo_documento td (cost=0.00..1.03 rows=3 width=40) (actual time=0.029..0.034 rows=3 loops=1)"
" -> Seq Scan on estado_civil ec (cost=0.00..1.04 rows=4 width=17) (actual time=0.028..0.034 rows=4 loops=1)"
"Total runtime: 3770.985 ms"

y la definición del view y las tablas que la componen es esta:
-- View: "vw_personas"

-- DROP VIEW vw_personas;

CREATE OR REPLACE VIEW vw_personas AS
SELECT persona.idpersona, persona.idecivil, ec.ec_descripcion, persona.idtdoc, td.td_descripcion, persona.per_nrodoc, persona.per_nombres, persona.per_apellidos, persona.per_sexo, persona.per_fnac, persona.per_dl_calle, persona.per_dl_barrio, persona.per_dl_edif, persona.per_dl_piso, persona.per_dl_pta, persona.per_dl_ciudad, persona.per_dl_pais, persona.per_dl_ref, persona.per_dp_calle, persona.per_dp_barrio, persona.per_dp_edif, persona.per_dp_piso, persona.per_dp_pta, persona.per_dp_ciudad, persona.per_dp_pais, persona.per_dp_ref, persona.per_lab_telef, persona.per_lab_fax, persona.per_lab_cel, persona.per_part_telef, persona.per_part_fax, persona.per_part_cel, persona.per_email, persona.per_alta_fecha, persona.per_alta_por, persona.per_modif_fecha, persona.per_modif_por
FROM persona
JOIN estado_civil ec USING (idecivil)
JOIN tipo_documento td USING (idtdoc)
ORDER BY persona.per_apellidos, persona.per_nombres;

ALTER TABLE vw_personas OWNER TO postgres;

-- Table: persona

-- DROP TABLE persona;

CREATE TABLE persona
(
idpersona serial NOT NULL,
idecivil integer NOT NULL,
idtdoc integer NOT NULL,
per_nrodoc integer NOT NULL,
per_nombres character varying(160) NOT NULL,
per_apellidos character varying(160) NOT NULL,
per_sexo integer NOT NULL,
per_fnac date,
per_dl_calle character varying(95),
per_dl_barrio character varying(45),
per_dl_edif character varying(45),
per_dl_piso character varying(12),
per_dl_pta character varying(12),
per_dl_ciudad character varying(65),
per_dl_pais character varying(65),
per_dl_ref text,
per_dp_calle character varying(95),
per_dp_barrio character varying(45),
per_dp_edif character varying(45),
per_dp_piso character varying(12),
per_dp_pta character varying(12),
per_dp_ciudad character varying(65),
per_dp_pais character varying(65),
per_dp_ref text,
per_lab_telef character varying(18),
per_lab_fax character varying(18),
per_lab_cel character varying(18),
per_part_telef character varying(18),
per_part_fax character varying(18),
per_part_cel character varying(18),
per_email character varying(48),
per_alta_fecha timestamp with time zone DEFAULT now(),
per_alta_por character varying(65) DEFAULT "current_user"(),
per_modif_fecha timestamp with time zone DEFAULT now(),
per_modif_por character varying(65) DEFAULT "current_user"(),
temp_fnac character varying(65),
CONSTRAINT pk_persona PRIMARY KEY (idpersona),
CONSTRAINT idecivil_ecivil FOREIGN KEY (idecivil)
REFERENCES estado_civil (idecivil) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE RESTRICT,
CONSTRAINT idtdoc_tdocumento FOREIGN KEY (idtdoc)
REFERENCES tipo_documento (idtdoc) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE RESTRICT
)
WITHOUT OIDS;
ALTER TABLE persona OWNER TO infosur;

-- Table: estado_civil

-- DROP TABLE estado_civil;

CREATE TABLE estado_civil
(
idecivil serial NOT NULL,
ec_descripcion character varying(65) NOT NULL,
CONSTRAINT pk_ecivil PRIMARY KEY (idecivil)
)
WITHOUT OIDS;
ALTER TABLE estado_civil OWNER TO infosur;

-- Table: tipo_documento

-- DROP TABLE tipo_documento;

CREATE TABLE tipo_documento
(
idtdoc serial NOT NULL,
td_descripcion character varying(65) NOT NULL,
CONSTRAINT pk_tdocumento PRIMARY KEY (idtdoc)
)
WITHOUT OIDS;
ALTER TABLE tipo_documento OWNER TO infosur;

habría posibilidad de mejorarla? gracias a todos de antemano

Cordiales saludos,

-------------------
Ever Daniel Barreto Rojas
e.mail: ebarreto(at)nexusit(dot)com(dot)py :: Nexus Information Technologies
web: www.nexusit.com.py
29/05/2007 05:47 p.m.

---------------------
Investigación es lo que hago cuando no se lo que estoy haciendo.
- Anónimo
---------------------

Ever Daniel Barreto Rojas escribió:
> hola a todos
>
> estoy buscando mejorar el tiempo de una consulta sql que actualmente
> lleva entre 3000 y 5000 ms, entiendo que es un tiempo razonable,
> pero me gustaría saber si habría alguna posibilidad de mejorarlo aún
> más

Prueba creando un indice asi:

create index foobar on per_nombres (per_apellidos varchar_pattern_ops,
per_nombres varchar_pattern_ops)

Es posible que sea mas conveniente crear el indice solamente con el
apellido. Esto significaria que tendria que recorrer todas las personas
de un mismo apellido y filtrar segun el nombre despues, lo que significa
recorrer una mayor parte del indice, pero por otro lado cada entrada del
indice sera menor por lo tanto el indice sera menor, por lo tanto
tendras mejor uso del cache.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

álvaro:

El 29/05/2007 a las 08:26 p.m., escribiste:
> Prueba creando un indice asi:
> create index foobar on per_nombres (per_apellidos varchar_pattern_ops,
> per_nombres varchar_pattern_ops)
> Es posible que sea mas conveniente crear el indice solamente con el
> apellido. Esto significaria que tendria que recorrer todas las personas
> de un mismo apellido y filtrar segun el nombre despues, lo que significa
> recorrer una mayor parte del indice, pero por otro lado cada entrada del
> indice sera menor por lo tanto el indice sera menor, por lo tanto
> tendras mejor uso del cache.

explain analyze
select *
from vw_personas
where per_nombres like 'EVER DA%' and per_apellidos like 'BARRETO R%'

"Sort (cost=11.54..11.55 rows=1 width=2252) (actual time=0.480..0.482 rows=1 loops=1)"
" Sort Key: persona.per_apellidos, persona.per_nombres"
" -> Nested Loop (cost=0.00..11.53 rows=1 width=2252) (actual time=0.334..0.432 rows=1 loops=1)"
" Join Filter: (persona.idecivil = ec.idecivil)"
" -> Nested Loop (cost=0.00..10.44 rows=1 width=2239) (actual time=0.318..0.401 rows=1 loops=1)"
" Join Filter: (persona.idtdoc = td.idtdoc)"
" -> Index Scan using idx_personas on persona (cost=0.00..9.38 rows=1 width=2203) (actual time=0.287..0.361 rows=1 loops=1)"
" Index Cond: (((per_apellidos)::text ~>=~ 'BARRETO R'::character varying) AND ((per_apellidos)::text ~<~ 'BARRETO S'::character varying) AND ((per_nombres)::text ~>=~ 'EVER DA'::character varying) AND ((per_nombres)::text ~<~ 'EVER DB'::character varying))"
" Filter: (((per_nombres)::text ~~ 'EVER DA%'::text) AND ((per_apellidos)::text ~~ 'BARRETO R%'::text))"
" -> Seq Scan on tipo_documento td (cost=0.00..1.03 rows=3 width=40) (actual time=0.006..0.010 rows=3 loops=1)"
" -> Seq Scan on estado_civil ec (cost=0.00..1.04 rows=4 width=17) (actual time=0.004..0.011 rows=4 loops=1)"
"Total runtime: 3.781 ms"

creo que no hace falta decir nada, esto funcionó de perlas!!!...
muchísimas gracias!!!

el índice creado:
CREATE INDEX idx_personas
ON persona
USING btree
(per_apellidos varchar_pattern_ops, per_nombres varchar_pattern_ops);

encontré en el manual lo que me sugeriste bajo "Operator Class",
hay algun lugar en donde pueda encontrar más información?

Cordiales saludos,

-------------------
Ever Daniel Barreto Rojas
e.mail: ebarreto(at)nexusit(dot)com(dot)py :: Nexus Information Technologies
web: www.nexusit.com.py
29/05/2007 09:18 p.m.

---------------------
Cuando menos sabes,
más crees...
---------------------

Como o en donde busco, para poner en cero el tipo de dato serial una vez
que la tabla se le aplica un delete..?????

Gracias
Mario

Mario Cassanelli escribió:
> Como o en donde busco, para poner en cero el tipo de dato serial una vez
> que la tabla se le aplica un delete..?????

Usa la funcion setval()

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

Cuanto duraba la consulta original? En segundos?

Puedes decirnos en cuanto mejoro esto?
Alvaro, puedes explicar el asunto de los patterns, no entendi eso muy bien.

*-------------------------------------------------------*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas
*-809-747-2787
* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo
comun"
*-------------------------------------------------------*

>From: Ever Daniel Barreto Rojas <ebarreto(at)nexusit(dot)com(dot)py>
>Reply-To: Ever Daniel Barreto Rojas <ebarreto(at)nexusit(dot)com(dot)py>
>To: pgsql-es-ayuda(at)postgresql(dot)org
>Subject: Re[2]: [pgsql-es-ayuda] velocidad en consulta con like
>Date: Tue, 29 May 2007 21:31:19 -0400
>
>álvaro:
>
>El 29/05/2007 a las 08:26 p.m., escribiste:
> > Prueba creando un indice asi:
> > create index foobar on per_nombres (per_apellidos varchar_pattern_ops,
> > per_nombres varchar_pattern_ops)
> > Es posible que sea mas conveniente crear el indice solamente con el
> > apellido. Esto significaria que tendria que recorrer todas las personas
> > de un mismo apellido y filtrar segun el nombre despues, lo que significa
> > recorrer una mayor parte del indice, pero por otro lado cada entrada del
> > indice sera menor por lo tanto el indice sera menor, por lo tanto
> > tendras mejor uso del cache.
>
>explain analyze
>select *
>from vw_personas
>where per_nombres like 'EVER DA%' and per_apellidos like 'BARRETO R%'
>
>"Sort (cost=11.54..11.55 rows=1 width=2252) (actual time=0.480..0.482
>rows=1 loops=1)"
>" Sort Key: persona.per_apellidos, persona.per_nombres"
>" -> Nested Loop (cost=0.00..11.53 rows=1 width=2252) (actual
>time=0.334..0.432 rows=1 loops=1)"
>" Join Filter: (persona.idecivil = ec.idecivil)"
>" -> Nested Loop (cost=0.00..10.44 rows=1 width=2239) (actual
>time=0.318..0.401 rows=1 loops=1)"
>" Join Filter: (persona.idtdoc = td.idtdoc)"
>" -> Index Scan using idx_personas on persona
>(cost=0.00..9.38 rows=1 width=2203) (actual time=0.287..0.361 rows=1
>loops=1)"
>" Index Cond: (((per_apellidos)::text ~>=~ 'BARRETO
>R'::character varying) AND ((per_apellidos)::text ~<~ 'BARRETO
>S'::character varying) AND ((per_nombres)::text ~>=~ 'EVER DA'::character
>varying) AND ((per_nombres)::text ~<~ 'EVER DB'::character varying))"
>" Filter: (((per_nombres)::text ~~ 'EVER DA%'::text) AND
>((per_apellidos)::text ~~ 'BARRETO R%'::text))"
>" -> Seq Scan on tipo_documento td (cost=0.00..1.03 rows=3
>width=40) (actual time=0.006..0.010 rows=3 loops=1)"
>" -> Seq Scan on estado_civil ec (cost=0.00..1.04 rows=4 width=17)
>(actual time=0.004..0.011 rows=4 loops=1)"
>"Total runtime: 3.781 ms"
>
> creo que no hace falta decir nada, esto funcionó de perlas!!!...
> muchísimas gracias!!!
>
> el índice creado:
>CREATE INDEX idx_personas
> ON persona
> USING btree
> (per_apellidos varchar_pattern_ops, per_nombres varchar_pattern_ops);
>
> encontré en el manual lo que me sugeriste bajo "Operator Class",
> hay algun lugar en donde pueda encontrar más información?
>
>Cordiales saludos,
>
>-------------------
>Ever Daniel Barreto Rojas
>e.mail: ebarreto(at)nexusit(dot)com(dot)py :: Nexus Information Technologies
>web: www.nexusit.com.py
>29/05/2007 09:18 p.m.
>
>---------------------
>Cuando menos sabes,
>más crees...
>---------------------
>
>
>---------------------------(fin del mensaje)---------------------------
>TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
>
> http://archives.postgresql.org/pgsql-es-ayuda

_________________________________________________________________
Visita MSN Latino Noticias: Todo lo que pasa en el mundo y en tu paín, ¡en
tu idioma! http://latino.msn.com/noticias/

edwin:

El 02/06/2007 a las 12:07 p.m., escribiste:
> Cuanto duraba la consulta original? En segundos?
> Puedes decirnos en cuanto mejoro esto?
> Alvaro, puedes explicar el asunto de los patterns, no entendi eso muy bien.

la consulta original duraba entre 3 y 5 segundos, era variable,
pero no bajaba de los 3 segundos, después de crear los índices
según las especificaciones que me dió Alvaro, el tiempo de la
consulta bajó a aprox. 422 ms, como te darás cuenta, la diferencia
es muy grande

el asunto de los patterns yo tampoco lo entiendo, eso lo dejo a
cargo de la gente que más entiende

Cordiales saludos,

-------------------
Ever Daniel Barreto Rojas
e.mail: ebarreto(at)nexusit(dot)com(dot)py :: Nexus Information Technologies
web: www.nexusit.com.py
02/06/2007 03:25 p.m.

---------------------
Algunos persiguen la felicidad; otros la crean.
---------------------

edwin:

El 02/06/2007 a las 12:07 p.m., escribiste:
> Cuanto duraba la consulta original? En segundos?
> Puedes decirnos en cuanto mejoro esto?

olvidé de escribirte el explain analyze con el nuevo índice:

la consulta:
explain analyze
select *
from vw_personas
where per_nombres like 'EVER DA%' and per_apellidos like 'BARRETO R%'

el explain analyze:

"Sort (cost=11.54..11.55 rows=1 width=2252) (actual time=0.445..0.446 rows=1 loops=1)"
" Sort Key: persona.per_apellidos, persona.per_nombres"
" -> Nested Loop (cost=0.00..11.53 rows=1 width=2252) (actual time=0.315..0.412 rows=1 loops=1)"
" Join Filter: (persona.idecivil = ec.idecivil)"
" -> Nested Loop (cost=0.00..10.44 rows=1 width=2239) (actual time=0.301..0.383 rows=1 loops=1)"
" Join Filter: (persona.idtdoc = td.idtdoc)"
" -> Index Scan using idx_personas on persona (cost=0.00..9.38 rows=1 width=2203) (actual time=0.273..0.348 rows=1 loops=1)"
" Index Cond: (((per_apellidos)::text ~>=~ 'BARRETO R'::character varying) AND ((per_apellidos)::text ~<~ 'BARRETO S'::character varying) AND ((per_nombres)::text ~>=~ 'EVER DA'::character varying) AND ((per_nombres)::text ~<~ 'EVER DB'::character varying))"
" Filter: (((per_nombres)::text ~~ 'EVER DA%'::text) AND ((per_apellidos)::text ~~ 'BARRETO R%'::text))"
" -> Seq Scan on tipo_documento td (cost=0.00..1.03 rows=3 width=40) (actual time=0.006..0.011 rows=3 loops=1)"
" -> Seq Scan on estado_civil ec (cost=0.00..1.04 rows=4 width=17) (actual time=0.003..0.009 rows=4 loops=1)"
"Total runtime: 0.672 ms"

Cordiales saludos,

-------------------
Ever Daniel Barreto Rojas
e.mail: ebarreto(at)nexusit(dot)com(dot)py :: Nexus Information Technologies
web: www.nexusit.com.py
02/06/2007 03:35 p.m.

---------------------
Cuando menos sabes,
más crees...
---------------------

On 5/29/07, Ever Daniel Barreto Rojas <ebarreto(at)nexusit(dot)com(dot)py> wrote:

>
> la consulta que estoy realizando es esta:
> SELECT *
> FROM vw_personas
> WHERE per_nombres LIKE 'EVER D%' AND per_apellidos LIKE 'BARRET%'
>
> sobre una tabla con 4.140.619 registros, el explain analyze de la
> consulta es esta:
>
> "Sort (cost=138124.45..138124.46 rows=1 width=2252) (actual time=3770.737..3770.740 rows=1 loops=1)"
> " Sort Key: persona.per_apellidos, persona.per_nombres"
> " -> Nested Loop (cost=0.00..138124.44 rows=1 width=2252) (actual time=2663.531..3770.693 rows=1 loops=1)"
> " Join Filter: (persona.idecivil = ec.idecivil)"
> " -> Nested Loop (cost=0.00..138123.35 rows=1 width=2239) (actual time=2663.484..3770.631 rows=1 loops=1)"
> " Join Filter: (persona.idtdoc = td.idtdoc)"
> " -> Seq Scan on persona (cost=0.00..138122.29 rows=1 width=2203) (actual time=2663.411..3770.548 rows=1 loops=1)"
> " Filter: (((per_nombres)::text ~~ 'EVER D%'::text) AND ((per_apellidos)::text ~~ 'BARRET%'::text))"

Aunque Alvaro ya te ayudo a resolver esto, es interesante mirar el
EXPLAIN ANALYZE. Por ejemplo, si te fijas el costo se vuelve alto a
partir de esta linea, que hay ahi un Seq Scan on persona, mirando a
que puede hacerlo tan feo existen 2 razones:

1) la cantidad de registros, un recorrido secuencial en esta tabla
sera pesado (de ahi es de donde Alvaro saco la sugerencia del indice
=)

2) fijate en la palabra width dice 2203, este es el tamaño promedio de
las filas que vas a retornar en el select. significa que cada fila
tiene 2kB puesto que postgres maneja (a menos que se cambie al momento
de compilar) paginas de 8kB.
eso significa que tus 4.140.619 registros se leen a razon de 4 por
pagina. en los cuales puede haber tanto tuplas vivas como muertas. No
se cuantas paginas lee postgres en un solo movimiento de e/s (Alvaro?)
pero definitivamente explica la subida de costos

aun cuando ya solucionaste tu problema fijate en la linea
correspondiente del nuevo explain
-> Index Scan using idx_personas on persona (cost=0.00..9.38
rows=1 width=2203) (actual time=0.273..0.348 rows=1 loops=1)"

y comparala con el Seq Scan de una tabla con menos columnas
-> Seq Scan on tipo_documento td (cost=0.00..1.03
rows=3 width=40) (actual time=0.006..0.011 rows=3 loops=1)"

fijate en el costo verdad que aun hay diferencia? el indice
probablemente era necesario por la cantidad de registros pero aun te
afecta el tamaño de cada registro porque postgres luego de leer el
indice debe accesar a la tabla (recuperar una pagina para verificar la
tupla esta viva)

si tu consulta no retornara una sola tupla y tus datos no estan
ordenados en la tabla (de modo que tengas que leer varias paginas para
obtener la informacion) te daras cuenta de lo que hablo.

Moraleja: cuiden esos diseños:

por ejemplo, estos evidentemente pudieron estar en otra tabla.
per_dl_calle character varying(95),
per_dl_barrio character varying(45),
per_dl_edif character varying(45),
per_dl_piso character varying(12),
per_dl_pta character varying(12),
per_dl_ciudad character varying(65),
per_dl_pais character varying(65),
per_dl_ref text,
per_dp_calle character varying(95),
per_dp_barrio character varying(45),
per_dp_edif character varying(45),
per_dp_piso character varying(12),
per_dp_pta character varying(12),
per_dp_ciudad character varying(65),
per_dp_pais character varying(65),
per_dp_ref text,

y estos en otra
per_lab_telef character varying(18),
per_lab_fax character varying(18),
per_lab_cel character varying(18),
per_part_telef character varying(18),
per_part_fax character varying(18),
per_part_cel character varying(18),

solo por mencionar algunos ejemplos =)

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

Todos los indices basados en varchars deberían usar el "varchar_pattern_ops"
??
Qué diferencia tiene si no uso esta opción ???

Atentamente,

RAUL DUQUE
Bogotá, COlombia

----- Original Message -----
From: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
To: "Ever Daniel Barreto Rojas" <ebarreto(at)nexusit(dot)com(dot)py>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Tuesday, May 29, 2007 7:26 PM
Subject: Re: [pgsql-es-ayuda] velocidad en consulta con like

> Ever Daniel Barreto Rojas escribió:
>> hola a todos
>>
>> estoy buscando mejorar el tiempo de una consulta sql que actualmente
>> lleva entre 3000 y 5000 ms, entiendo que es un tiempo razonable,
>> pero me gustaría saber si habría alguna posibilidad de mejorarlo aún
>> más
>
> Prueba creando un indice asi:
>
> create index foobar on per_nombres (per_apellidos varchar_pattern_ops,
> per_nombres varchar_pattern_ops)
>
> Es posible que sea mas conveniente crear el indice solamente con el
> apellido. Esto significaria que tendria que recorrer todas las personas
> de un mismo apellido y filtrar segun el nombre despues, lo que significa
> recorrer una mayor parte del indice, pero por otro lado cada entrada del
> indice sera menor por lo tanto el indice sera menor, por lo tanto
> tendras mejor uso del cache.
>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
>
> http://archives.postgresql.org/pgsql-es-ayuda
>
> __________ Información de NOD32, revisión 2295 (20070529) __________
>
> Este mensaje ha sido analizado con NOD32 antivirus system
> http://www.nod32.com
>
>

On 6/3/07, Raúl Andrés Duque <raulandresduque(at)hotmail(dot)com> wrote:
> Todos los indices basados en varchars deberían usar el "varchar_pattern_ops"
> ??
> Qué diferencia tiene si no uso esta opción ???
>

por favor, no reenvies la misma pregunta varias veces, no le da mas
fuerza ni la hara mas prioritaria.

la documentacion explica claramente el asunto
http://www.postgresql.org/docs/8.2/static/indexes-opclass.html

o una simple prueba te hubiera bastado. cuentanos que resultado da tu
prueba y a que conslusiones llegaste

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

Edwin Quijada escribió:
>
> Cuanto duraba la consulta original? En segundos?
>
> Puedes decirnos en cuanto mejoro esto?
> Alvaro, puedes explicar el asunto de los patterns, no entendi eso muy bien.

El problema es que los operadores normales de cadenas de texto funcionan
con la funcion strcoll. Pero las busquedas con LIKE no pueden usar
indices construidos con este operador, por alguna razon que se me escapa
en este momento. Entonces, la solucion es crear un indice con
_pattern_ops que es una clase de operadores que hace que las
comparaciones se hagan byte por byte en lugar de hacerlas con strcoll.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.