Re: Tiempo de consulta con full text search

Ever

Tengo una duda, vos usas esa base para buscar nombres
de personas?.
Te pregunto esto porque me parece que el fuerte de FTS
(full text search) es para buscar palabras dentro de
documentos,no se cuanto ganas al usar FTS para buscar
nombres, me entendes?
Porque FTS usa diccionarios, stop words ( palabras que
ignora, gralmente preposiciones y otras )
y busqueda por lexemes, o sea a la palabra la pasa al
infinitivo singular y busca por la raiz. esto te
permite si buscas por ejemplo 'mujer' , que te traiga
'mujercitas' , mujeres, etc... porque todas las pasa a
mujer. ademas de sinónimos etc.
NO estoy tan convencido que para buscar nombres
propios tengas alguna ventaja con FTS.
Puedo estar herrado ,pero esa es mi primera opinion

saludos y feliz 2008 para todos
MDC
--- Ever Daniel Barreto Rojas
<ebarreto(at)nexusit(dot)com(dot)py> escribió:

> Hola a todos:
>
> Hace algún tiempo atrás tuve una consulta de cómo
> mejorar el
> tiempo de una consulta en la que utilizaba LIKE
> para realizar
> búsquedas sobre campos varchar, y en aquella
> oportunidad, me
> comentaron que debía usar full text search para
> mejorar aún más
> el tiempo de las consultas
>
> pues bien, finalmente lo hice, esta semana me tomé
> el tiempo de
> montar un servidor en donde hacer las pruebas, asi
> es que
> básicamente, lo que necesito es mejorar (si se
> puede), el tiempo
> de una consulta, la consulta es la siguiente:
>
> -- la tabla persona tiene 4 millones de registros
> --
>
> infosur=# \timing
> Mostrar tiempos está activado.
> infosur=# SELECT per_nrodoc, per_apellidos,
> per_nombres
> infosur-# FROM persona
> infosur-# WHERE idx_fti_nombrecompleto @@
> to_tsquery('default', 'EVER&BARRETO')
> infosur-# ORDER BY per_apellidos, per_nombres;
> Duración: 8420,236 ms
>
> como ven, la consulta me toma 8420ms, sin embargo
> si vuelvo a
> ejecutarla, obtengo un mejor tiempo:
>
> infosur=# SELECT per_nrodoc, per_apellidos,
> per_nombres
> FROM persona
> WHERE idx_fti_nombrecompleto @@
> to_tsquery('default', 'EVER&BARRETO')
> ORDER BY per_apellidos, per_nombres;
> Duración: 157,586 ms
>
> pero si cambio las palabras de búsqueda, vuelvo a
> obtener una
> tiempo mayor:
>
> infosur=# SELECT per_nrodoc, per_apellidos,
> per_nombres
> FROM persona
> WHERE idx_fti_nombrecompleto @@
> to_tsquery('default', 'HUGO&BARRETO')
> ORDER BY per_apellidos, per_nombres;
> Duración: 12947,179 ms
>
> habría alguna forma de mejorar esto? el escenario
> es el siguiente:
>
> Debian 4.0r1 para AMD64
> PostgreSQL 8.2.5 on x86_64-pc-linux-gnu, compiled
> by GCC cc (GCC)
> 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
>
> la estructura de la tabla persona y los pasos que
> hice para crear el
> campo y el indice tsearch están disponibles en el
> archivo de
> texto que va adjunto a este mail
>
> muchas gracias a todos por su ayuda, y que espero
> que tengan un
> excelente 2008!
>
> Cordiales saludos,
>
> -------------------
> Ever Daniel Barreto Rojas
> e.mail: ebarreto(at)nexusit(dot)com(dot)py :: Nexus Information
> Technologies
> web: www.nexusit.com.py
> 02/01/2008 12:40 p.m.
>
> ---------------------
> "Hay cuatro cosas que no pueden ser escondidas
> durante mucho tiempo:
> la ciencia, la estupidez, la riqueza y la pobreza"
> - Averroes
> ---------------------> Proceso realizado para añadir
full text search a la
> tabla persona:
> ---
>
> ALTER TABLE persona
> ADD COLUMN idx_fti_nombrecompleto tsvector;
> VACUUM FULL ANALYZE;
> CREATE INDEX idx_fti_nombrecompleto_idx
> ON persona USING gist(idx_fti_nombrecompleto);
> VACUUM FULL ANALYZE;
> CREATE TRIGGER bu_bi_persona_tsearch BEFORE UPDATE
> OR INSERT ON persona
> FOR EACH ROW EXECUTE PROCEDURE
> tsearch2(idx_fti_nombrecompleto, per_nombres,
> per_apellidos);
>
> Esquema de la tabla persona:
> ---
> infosur=# \d persona
> Tabla
> «public.persona»
> Columna | Tipo |
> Modificadores
>
------------------------+--------------------------+-------------------------------------------------------------
> idpersona | integer |
> not null default
> nextval('persona_idpersona_seq'::regclass)
> 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_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) |
> idx_fti_nombrecompleto | tsvector |
> Índices:
> «pk_persona» PRIMARY KEY, btree (idpersona)
> «idx_fti_nombrecompleto_idx» gist
> (idx_fti_nombrecompleto)
> «idx_nro_cedula» btree (per_nrodoc)
> «idx_personas» btree (per_apellidos
> varchar_pattern_ops, per_nombres
> varchar_pattern_ops)
> Restricciones de llave foránea:
> «idecivil_ecivil» FOREIGN KEY (idecivil)
> REFERENCES estado_civil(idecivil) ON UPDATE CASCADE
> ON DELETE RESTRICT
> «idtdoc_tdocumento» FOREIGN KEY (idtdoc)
> REFERENCES tipo_documento(idtdoc) ON UPDATE CASCADE
> ON DELETE RESTRICT
> Triggers:
> bu_bi_persona_tsearch BEFORE INSERT OR UPDATE ON
> persona FOR EACH ROW EXECUTE PROCEDURE
> tsearch2('idx_fti_nombrecompleto', 'per_nombres',
> 'per_apellidos')
> > --
> TIP 1: para suscribirte y desuscribirte, visita
> http://archives.postgresql.org/pgsql-es-ayuda
>

Tarjeta de crédito Yahoo! de Banco Supervielle.
Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. www.tuprimeratarjeta.com.ar