Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] optimización de busqueda por like

Buenas tardes,

Resulta que tengo una función que realiza varias validaciones, inserciones
etc. Una de ellas es realizar búsqueda por like a una tabla. Básicamente
tengo dos tablas "alumno" y "persona", a cada alumno se debe buscar en la
tabla persona, y para ello solo contamos con nombres y apellidos (nombre
completo, es decir en un solo campo y campos separados, es decir nombre1,
nombre2, apellido1, apellido2), por lo que inicialmente procedemos a buscar
por "=", considerando mayusculas, minusculas, caracteres especiales, si eso
no emite resultado procedemos a buscar por like en los campos separados, y
si nuevamente no emite resultados, se realiza nuevamente la búsqueda por
like en el campo que contiene el nombre y apellido completo.

La tabla persona en la que se realiza la búsqueda tiene aproximadamente
580000 registros. Probé con indices btree, y también leí acerca de
varchar_pattern_ops, pero con éste ultimo no es posible utilizar "es
igual", por lo que no me resulta.

Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
aproximadamente, lo cual es mas que excesivo.

Alguna idea?

Desde ya, gracias.

Ana Ramirez.-

El 15 de noviembre de 2011 14:11, Anita Ramirez <anita(dot)ins(at)gmail(dot)com>escribió:

>
> Buenas tardes,
>
> Resulta que tengo una función que realiza varias validaciones, inserciones
> etc. Una de ellas es realizar búsqueda por like a una tabla. Básicamente
> tengo dos tablas "alumno" y "persona", a cada alumno se debe buscar en la
> tabla persona, y para ello solo contamos con nombres y apellidos (nombre
> completo, es decir en un solo campo y campos separados, es decir nombre1,
> nombre2, apellido1, apellido2), por lo que inicialmente procedemos a buscar
> por "=", considerando mayusculas, minusculas, caracteres especiales, si eso
> no emite resultado procedemos a buscar por like en los campos separados, y
> si nuevamente no emite resultados, se realiza nuevamente la búsqueda por
> like en el campo que contiene el nombre y apellido completo.
>
> La tabla persona en la que se realiza la búsqueda tiene aproximadamente
> 580000 registros. Probé con indices btree, y también leí acerca de
> varchar_pattern_ops, pero con éste ultimo no es posible utilizar "es
> igual", por lo que no me resulta.
>
> Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
> aproximadamente, lo cual es mas que excesivo.
>
> Alguna idea?
>
> Desde ya, gracias.
>
> Ana Ramirez.-
>

Revisa los indices y pk, habitualmente esto se produce por un ml diseño de
BBDD

atte.

--
Sin más que decir se despide de Usted, muy atentamente

Cesar Erices Vergara
Ingeniero en Gestión Informática
Analista de Sistema

Santiago - Chile

El 16/11/2011 01:22 p.m., Cesar Erices escribió:
> El 15 de noviembre de 2011 14:11, Anita Ramirez <anita(dot)ins(at)gmail(dot)com
> <mailto:anita(dot)ins(at)gmail(dot)com>> escribió:
>
>
> Buenas tardes,
>
> Resulta que tengo una función que realiza varias validaciones,
> inserciones etc. Una de ellas es realizar búsqueda por like a una
> tabla. Básicamente tengo dos tablas "alumno" y "persona", a cada
> alumno se debe buscar en la tabla persona, y para ello solo
> contamos con nombres y apellidos (nombre completo, es decir en un
> solo campo y campos separados, es decir nombre1, nombre2,
> apellido1, apellido2), por lo que inicialmente procedemos a buscar
> por "=", considerando mayusculas, minusculas, caracteres
> especiales, si eso no emite resultado procedemos a buscar por like
> en los campos separados, y si nuevamente no emite resultados, se
> realiza nuevamente la búsqueda por like en el campo que contiene
> el nombre y apellido completo.
>
> La tabla persona en la que se realiza la búsqueda tiene
> aproximadamente 580000 registros. Probé con indices btree, y
> también leí acerca de varchar_pattern_ops, pero con éste ultimo no
> es posible utilizar "es igual", por lo que no me resulta.
>
> Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
> aproximadamente, lo cual es mas que excesivo.
>
> Alguna idea?
>
> Desde ya, gracias.
>
> Ana Ramirez.-
>
>
> Revisa los indices y pk, habitualmente esto se produce por un ml
> diseño de BBDD
>
> atte.
>
> --
> Sin más que decir se despide de Usted, muy atentamente
>
> Cesar Erices Vergara
> Ingeniero en Gestión Informática
> Analista de Sistema
>
> Santiago - Chile
>
> Se certificó que el correo no contiene virus.
> Comprobada por AVG - www.avg.es <http://www.avg.es>
> Versión: 2012.0.1869 / Base de datos de virus: 2092/4620 - Fecha de la
> versión: 16/11/2011
>
Hola, que caracteristicas tiene el equipo de la bd.
Como es la cnsulta de like que estas usando?
es algo asi : select * from persona where coalesce(apellido1,'')||'
'||colaesce(apellido2,'')||' '||coalesce(nombre1,'')||'
'||colaesce(nombre2,'') ilike '%rodriguez fernando%'

saludos fernando rodriguez

El día 15 de noviembre de 2011 19:11, Anita Ramirez
<anita(dot)ins(at)gmail(dot)com> escribió:
>
> Buenas tardes,
>
> Resulta que tengo una función que realiza varias validaciones, inserciones
> etc. Una de ellas es realizar búsqueda por like a una tabla. Básicamente
> tengo dos tablas "alumno" y "persona", a cada alumno  se debe buscar en la
> tabla persona, y para ello solo contamos con nombres y apellidos (nombre
> completo, es decir en un solo campo y campos separados, es decir nombre1,
> nombre2, apellido1, apellido2), por lo que inicialmente procedemos a buscar
> por "=", considerando mayusculas, minusculas, caracteres especiales, si eso
> no emite resultado procedemos a buscar por like en los campos separados, y
> si nuevamente no emite resultados, se realiza nuevamente la búsqueda por
> like en el campo que contiene el nombre y apellido completo.
>
> La tabla persona en la que se realiza la búsqueda tiene aproximadamente
> 580000 registros. Probé con indices btree, y también leí acerca de
> varchar_pattern_ops, pero con éste ultimo no es posible utilizar "es igual",
> por lo que no me resulta.
>
> Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
> aproximadamente, lo cual es mas que excesivo.
>
> Alguna idea?
>
> Desde ya, gracias.
>
> Ana Ramirez.-
>

Migrar a 9.1 es una opción?

http://palominodb.com/blog/2011/10/12/indexing-text-columns-gist-or-gin-optimize-ilike-using-pgtrgm-postgres-91-part-1

--
--
              Emanuel Calvo
              Helpame.com

Excerpts from Anita Ramirez's message of mar nov 15 15:11:24 -0300 2011:
> Buenas tardes,
>
> Resulta que tengo una función que realiza varias validaciones, inserciones
> etc. Una de ellas es realizar búsqueda por like a una tabla. Básicamente
> tengo dos tablas "alumno" y "persona", a cada alumno se debe buscar en la
> tabla persona, y para ello solo contamos con nombres y apellidos (nombre
> completo, es decir en un solo campo y campos separados, es decir nombre1,
> nombre2, apellido1, apellido2),

Eso me huele a mal diseño. ¿No debería haber una llave foránea en
alumno que apunte a un registro específico en persona? Si cada alumno
es también una persona, ¿qué sentido tiene almacenar los nombres y
apellidos en alumno, que ya están en persona?

> por lo que inicialmente procedemos a buscar
> por "=", considerando mayusculas, minusculas, caracteres especiales, si eso
> no emite resultado procedemos a buscar por like en los campos separados, y
> si nuevamente no emite resultados, se realiza nuevamente la búsqueda por
> like en el campo que contiene el nombre y apellido completo.
>
> La tabla persona en la que se realiza la búsqueda tiene aproximadamente
> 580000 registros. Probé con indices btree, y también leí acerca de
> varchar_pattern_ops, pero con éste ultimo no es posible utilizar "es
> igual", por lo que no me resulta.

Una idea simple sería tener dos índices, un btree normal y un btree con
varchar_pattern_ops. Eso te permitiría usar búsquedas con LIKE y al
mismo tiempo con =.

> Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
> aproximadamente, lo cual es mas que excesivo.

Hay algo muy mal en tu sistema.

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

Saludos a todos.
Me pueden ayudar con un problema que tengo en relación a diseñar un
procedimiento almacenado que actualiza una tabla en MySql utilizando
como fuente otra tabla pero que esta en MSSQL Server 2003. La BD de
Mysql esta en un servidor Debian
Espero que el planteamiento no sea ambigüo.
Gracias.

El 16 de noviembre de 2011 14:59, Carlos Agustín López Avila <
cagustinla(at)gmail(dot)com> escribió:

> Saludos a todos.
> Me pueden ayudar con un problema que tengo en relación a diseñar un
> procedimiento almacenado que actualiza una tabla en MySql utilizando como
> fuente otra tabla pero que esta en MSSQL Server 2003. La BD de Mysql esta
> en un servidor Debian
> Espero que el planteamiento no sea ambigüo.
> Gracias.
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org
> **)
> Para cambiar tu suscripción:
> http://www.postgresql.org/**mailpref/pgsql-es-ayuda<http://www.postgresql.org/mailpref/pgsql-es-ayuda>
>

No es la lista apropiada para esta consulta

--
Sin más que decir se despide de Usted, muy atentamente

Cesar Erices Vergara
Ingeniero en Gestión Informática
Analista de Sistema

Santiago - Chile

te equivocaste de lista

El 16 de noviembre de 2011 12:59, Carlos Agustín López Avila <
cagustinla(at)gmail(dot)com> escribió:

> Saludos a todos.
> Me pueden ayudar con un problema que tengo en relación a diseñar un
> procedimiento almacenado que actualiza una tabla en MySql utilizando como
> fuente otra tabla pero que esta en MSSQL Server 2003. La BD de Mysql esta
> en un servidor Debian
> Espero que el planteamiento no sea ambigüo.
> Gracias.
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org
> **)
> Para cambiar tu suscripción:
> http://www.postgresql.org/**mailpref/pgsql-es-ayuda<http://www.postgresql.org/mailpref/pgsql-es-ayuda>
>

--
ISC Miguel Angel Hernandez Moreno

Inicio del mensaje reenviado:

> De: Miguel Angel Hernandez Moreno <miguel(dot)hdz(dot)mrn(at)gmail(dot)com>
> Asunto: Re: [pgsql-es-ayuda] OT Desesperado
> Fecha: 16 de noviembre de 2011 13:17:55 CST
> Para: Carlos Agustín López Avila <cagustinla(at)gmail(dot)com>
> Cc: Ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
>
> te equivocaste de lista
>
> El 16 de noviembre de 2011 12:59, Carlos Agustín López Avila <cagustinla(at)gmail(dot)com> escribió:
> Saludos a todos.
> Me pueden ayudar con un problema que tengo en relación a diseñar un procedimiento almacenado que actualiza una tabla en MySql utilizando como fuente otra tabla pero que esta en MSSQL Server 2003. La BD de Mysql esta en un servidor Debian
> Espero que el planteamiento no sea ambigüo.
> Gracias.
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>
>
>
> --
> ISC Miguel Angel Hernandez Moreno
>

Quizá te puedan ayudar en:

mysql-es(at)lists(dot)mysql(dot)com

Saludos!

Juan Manuel Acuña.

El 16/11/2011 01:34 p.m., Juan Manuel Acuña Barrera escribió:
>
>
> Inicio del mensaje reenviado:
>
>> *De: *Miguel Angel Hernandez Moreno <miguel(dot)hdz(dot)mrn(at)gmail(dot)com
>> <mailto:miguel(dot)hdz(dot)mrn(at)gmail(dot)com>>
>> *Asunto: **Re: [pgsql-es-ayuda] OT Desesperado*
>> *Fecha: *16 de noviembre de 2011 13:17:55 CST
>> *Para: *Carlos Agustín López Avila <cagustinla(at)gmail(dot)com
>> <mailto:cagustinla(at)gmail(dot)com>>
>> *Cc: *Ayuda <pgsql-es-ayuda(at)postgresql(dot)org
>> <mailto:pgsql-es-ayuda(at)postgresql(dot)org>>
>>
>> te equivocaste de lista
>>
>> El 16 de noviembre de 2011 12:59, Carlos Agustín López Avila
>> <cagustinla(at)gmail(dot)com <mailto:cagustinla(at)gmail(dot)com>> escribió:
>>
>> Saludos a todos.
>> Me pueden ayudar con un problema que tengo en relación a diseñar
>> un procedimiento almacenado que actualiza una tabla en MySql
>> utilizando como fuente otra tabla pero que esta en MSSQL Server
>> 2003. La BD de Mysql esta en un servidor Debian
>> Espero que el planteamiento no sea ambigüo.
>> Gracias.
>> -
>> Enviado a la lista de correo pgsql-es-ayuda
>> (pgsql-es-ayuda(at)postgresql(dot)org
>> <mailto:pgsql-es-ayuda(at)postgresql(dot)org>)
>> Para cambiar tu suscripción:
>> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>>
>>
>>
>>
>> --
>> ISC Miguel Angel Hernandez Moreno
>>
>
> Quizá te puedan ayudar en:
>
> mysql-es(at)lists(dot)mysql(dot)com <mailto:mysql-es(at)lists(dot)mysql(dot)com>
>
> Saludos!
>
> Juan Manuel Acuña.
>
>
>
>
Gracias Juan Manuel Acuña.

La tabla alumnos es una especialización de la tabla personas, como dice
Alvaro, Alumnos debería tener una clave foranea apuntando a la persona
correspondiente. Alumnos no debería tener los otros datos que ya están en
la tabla personas.

Guillermo Villanueva

El 16 de noviembre de 2011 13:05, Alvaro Herrera
<alvherre(at)alvh(dot)no-ip(dot)org>escribió:

>
> Excerpts from Anita Ramirez's message of mar nov 15 15:11:24 -0300 2011:
> > Buenas tardes,
> >
> > Resulta que tengo una función que realiza varias validaciones,
> inserciones
> > etc. Una de ellas es realizar búsqueda por like a una tabla. Básicamente
> > tengo dos tablas "alumno" y "persona", a cada alumno se debe buscar en
> la
> > tabla persona, y para ello solo contamos con nombres y apellidos (nombre
> > completo, es decir en un solo campo y campos separados, es decir nombre1,
> > nombre2, apellido1, apellido2),
>
> Eso me huele a mal diseño. ¿No debería haber una llave foránea en
> alumno que apunte a un registro específico en persona? Si cada alumno
> es también una persona, ¿qué sentido tiene almacenar los nombres y
> apellidos en alumno, que ya están en persona?
>
> > por lo que inicialmente procedemos a buscar
> > por "=", considerando mayusculas, minusculas, caracteres especiales, si
> eso
> > no emite resultado procedemos a buscar por like en los campos separados,
> y
> > si nuevamente no emite resultados, se realiza nuevamente la búsqueda por
> > like en el campo que contiene el nombre y apellido completo.
> >
> > La tabla persona en la que se realiza la búsqueda tiene aproximadamente
> > 580000 registros. Probé con indices btree, y también leí acerca de
> > varchar_pattern_ops, pero con éste ultimo no es posible utilizar "es
> > igual", por lo que no me resulta.
>
> Una idea simple sería tener dos índices, un btree normal y un btree con
> varchar_pattern_ops. Eso te permitiría usar búsquedas con LIKE y al
> mismo tiempo con =.
>
> > Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
> > aproximadamente, lo cual es mas que excesivo.
>
> Hay algo muy mal en tu sistema.
>
> --
> Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org
> )
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>

Les explico basicamente el escenario. Los datos de alumnos son resultado de
planillas de calificaciones de entidades educativas que fueron
digitalizadas, mediante reconocimiento OCR se colocaron los datos de los
mismos en tablas temporales (en este caso alumno), en la BD provista por el
cliente (en la cual se encuentra la tabla persona) debemos ubicar dichos
alumnos, es por ello que no tenemos un id asociado entre alumno y persona,
y, necesariamente debe de buscarse por nombre/apellidos.

Esas tablas temporales resultantes de las planillas las colocamos en la BD
provista por el cliente, pero dentro de otro esquema.

En cuanto a migrar a la versión 9, no es una opción ya que el cliente tiene
otros datos para otros sistemas en el mismo servidor y por el momento no
quieren tocarlo por ello se encuentra con la versión 8.4.

La consulta sería algo como :

select id_persona from persona where coalesce(primer_nombre, '') like
'%'||nombre1||'%' and
coalesce(segundo_nombre, '') like
'%'||nombre2||'%' and
coalesce(primer_apellido, '') like
'%'||apellido1||'%' and
coalesce(segundo_apellido, '') like
'%'||apellido2||'%'
and numero_persona =cedula;

Las características del servidor (se encuentra virtualizado):
SO: Red Hat 5
Memoria: 10GB
Proc: 6 núcleos

Gracias por sus aportes, voy a probar con ambos indices, el btree y
varchar_pattern_ops, asi como tambien la opción de expresiones regulares.

Saludos,

Se digitalizaron planillas de calificaciones, y los datos encontrados en
dichas planillas se almacenaron en una BD temporal )
El 16 de noviembre de 2011 12:22, Cesar Erices <caerices(at)gmail(dot)com>escribió:

> El 15 de noviembre de 2011 14:11, Anita Ramirez <anita(dot)ins(at)gmail(dot)com>escribió:
>
>
>> Buenas tardes,
>>
>> Resulta que tengo una función que realiza varias validaciones,
>> inserciones etc. Una de ellas es realizar búsqueda por like a una tabla.
>> Básicamente tengo dos tablas "alumno" y "persona", a cada alumno se debe
>> buscar en la tabla persona, y para ello solo contamos con nombres y
>> apellidos (nombre completo, es decir en un solo campo y campos separados,
>> es decir nombre1, nombre2, apellido1, apellido2), por lo que inicialmente
>> procedemos a buscar por "=", considerando mayusculas, minusculas,
>> caracteres especiales, si eso no emite resultado procedemos a buscar por
>> like en los campos separados, y si nuevamente no emite resultados, se
>> realiza nuevamente la búsqueda por like en el campo que contiene el nombre
>> y apellido completo.
>>
>> La tabla persona en la que se realiza la búsqueda tiene aproximadamente
>> 580000 registros. Probé con indices btree, y también leí acerca de
>> varchar_pattern_ops, pero con éste ultimo no es posible utilizar "es
>> igual", por lo que no me resulta.
>>
>> Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
>> aproximadamente, lo cual es mas que excesivo.
>>
>> Alguna idea?
>>
>> Desde ya, gracias.
>>
>> Ana Ramirez.-
>>
>
> Revisa los indices y pk, habitualmente esto se produce por un ml diseño de
> BBDD
>
> atte.
>
> --
> Sin más que decir se despide de Usted, muy atentamente
>
> Cesar Erices Vergara
> Ingeniero en Gestión Informática
> Analista de Sistema
>
> Santiago - Chile
>

--
Ana Ramirez.-

Entiendo Anita, avisanos como te va con los índices entonces
Guillermo Villanueva