Entiendo, creo que es la solucion mas factible.
Muchas Gracias
El 20 de abril de 2015, 11:11, Alvaro Herrera
escribió:
> Diego Ayala escribió:
> > Justamente, ese es el problema, el campo RUC es un campo character para
> > ambas tablas (invitado y proveedor) debido a que por ciertas cuestione
Diego Ayala escribió:
> Justamente, ese es el problema, el campo RUC es un campo character para
> ambas tablas (invitado y proveedor) debido a que por ciertas cuestiones de
> proveedores se tienen registros con valores del tipo character ej
> (X-18575, E-4567), por lo tanto se debio utilizar ese
Justamente, ese es el problema, el campo RUC es un campo character para
ambas tablas (invitado y proveedor) debido a que por ciertas cuestiones de
proveedores se tienen registros con valores del tipo character ej
(X-18575, E-4567), por lo tanto se debio utilizar ese tipo de dato para
almacenar el
Diego Ayala escribió:
> Buenos dias, me gustaria saber si existe alguna forma de optimizar esta
> pequeña consulta que tengo, ya que el tiempo de duracion del mismo es de
> casi 2,7 seg., me parece que es bastante, ya que sera un consulta bastante
> usada por diferentes usuarios, por lo tanto quisi
Hola gente
--- El sáb 28-mar-09, Gabriel Ferro escribió:
> De: Gabriel Ferro
> Asunto: Re: [pgsql-es-ayuda] optimizar consulta
> Para: pgsql-es-ayuda@postgresql.org
> Fecha: sábado, 28 de marzo de 2009, 7:07 pm
>
> hahaaa...
> me olvidé de crearlo luego de reinstalar
2009/3/28 Gabriel Ferro :
>
> Me parece ver que cuando usas muchos select muy complejos con BD muy grandes
> terminas haciendo index a muchos (o casi
> todos) los campos.
cuando estaba en clase de base de datos nos dijo que como regla
debiamos crear un indice por cada fk que haya en una tabla...
hahaaa...
me olvidé de crearlo luego de reinstalar todo... y como las busquedas las hacia
con los tsvector no me daba cuenta (sumenle programando dos programas a la vez
para dos BD distintas... dos monitores. dos CPUme estoy volviendo
looocococoo).
Me parece ver que cuando usas muchos sele
2009/3/28 Gabriel Ferro :
>
> " Hash Cond: (personaloc.claveper =
> buscarexacta_persona.clave)"
> " -> Seq Scan on personaloc (cost=0.00..590170.10
> rows=19716510 width=23) (actual time=0.020..76586.971 rows=19716510 loops=1)"
parece bastante
> pregunta con esta parte
> (padrones.personas.clave in (select * from
> padrones.buscarexacta_persona('PIRULO ESTEBAN',''))
> esto funciona..?¿ no deberia de devolverte un error el in porque el
> subquery retorna mas de una columna?¿
>
retorna solo una, justamente la funcion es del tipo
Hola
El 27 de marzo de 2009 19:36, Gabriel Ferro
escribió:
>
> master tengo un select de la forma
>
> SELECT padrones.personas.numdoc, padrones.personas.nombre,
> padrones.personas.otrosnombres,padrones.personas.datos,
> padrones.personas.sexo, padrones.personas.fechanac, padrones.docu.tipo AS
CREATE OR REPLACE FUNCTION padrones.buscarexacta_persona(nom text)
RETURNS SETOF respuesta_buscar_persona AS
$BODY$
DECLARE
RESPUESTA respuesta_buscar_persona%ROWTYPE;
nombusca text;
BEGIN
nombusca= regexp_replace( replace(REGEXP_REPLACE(trim(upper(nom)),'( ){2,}', '
'),' ','&'), E'[\\s\'|:&()
2009/3/27 Gabriel Ferro :
> master tengo un select de la forma
>
>
> Donde buscarexacta_persona es una funcion que usa tsvector para realizar
> buquedas.
puedes mostrar la funcion?
> La cosa es que demora demasiado.
por favor, pasa el explain analyze de la consulta
--
Atentamente,
Jaime Casano
12 matches
Mail list logo
