Re: [pgsql-es-ayuda] Ayuda Consulta de fechas
Disculpen el reenvio, pero ya no recibi respuesta y no se si llego el correo, solo lo reenviare esta vez por si las dudas. Entre tanto les comento que probe la consulta en otra tabla con menos campos pero igual mas de (50 millones de registros)... en la cual no tengo ningun campo en nulo (pos si afectaba). y pasa exactamente lo mismo, hago la consulta con fechas entre 1 mes.. y tarda demasiado tiempo en traer datos ( mas de 5 minutos), pense que solo era en fechas pero tambien pasa en el id de la tabla ( importacionid) , se que postgresql soporta bases de datos mucho mas grandes a la que estoy manejando y supongo debe haber una forma de hacer mas rapidas estas consultas. De verdad necesito su ayuda ya que yo recomende ampliamente postgresql y ya me estan diciendo que debi seleccionar otro manejador de BD (llegue al proyecto como consultor y desarrollador de sistemas embebidos y ahora soy el DBA entre otras cosas). Saludos. Roberto Campos P.D. Ya comence con pruebas de particionamiento y aunque apenas llevo 2 particiones no he notado mejoria en la consulta que les presente. Aunque si en otro tipo de consultas que no requieren agrupación. El día 22 de julio de 2011 20:41, motum hesa escribió: > Alvaro una disculpa quise editar la consulta para que se viera mas > rapido el tipo de campo.. pero ahora que les mande la estructura pues > ya no es necesario > > >>Hmm, aquí no hay ninguna columna "idtbl". Por favor muestra la consulta >>y el explain analyze con los nombres correctos de las columnas, sin >>editorialización. > > Esta es la consulta original, ahorita cambio el tiempo que muestra el > explain debido a las fechas por las que voy. > > > select max(importacionid), min(importacionid), > unitno, flota > from datosentrada_his > where fechacreacion BETWEEN '2011-06-01 00:00:00' and '2011-07-01 > 23:59:59' > group by unitno,flota order by unitno > > "Sort (cost=969443.39..969445.32 rows=775 width=18)" > " Sort Key: unitno" > " -> HashAggregate (cost=969394.57..969406.19 rows=775 width=18)" > " -> Index Scan using ind_fecha on datosentrada_his > (cost=0.00..925042.61 rows=4435196 width=18)" > " Index Cond: ((fechacreacion >= '2011-06-01 > 00:00:00'::timestamp without time zone) AND (fechacreacion <= > '2011-07-01 23:59:59'::timestamp without time zone))" > > > > > > El día 22 de julio de 2011 18:08, Jaime Casanova > escribió: >> On Fri, Jul 22, 2011 at 5:16 PM, motum hesa wrote: >>> >>> Table "public.datosentrada_his" >>> Column | Type | Modifiers >>> -+-+--- >> >> aunque no es lo que preguntaste, te dire que tanto campo que acepta >> NULL me huele a mal diseño (especialmente porque hay campos que >> obviamente estan relacionados entre si de forma especial >> > > Hola Jaime, gracias por el comentario, efectivamente el sistema tenia > un mal diseño de base de datos cuando lo tome, yo he tratado de > mejorarlo con indices, llaves primarias y foraneas en donde debe ser, > trato de evitar la insercción de nullos en los campos que viste pero > no he cambiado la estructura, si es recomendable hoy mismo lo hago en > los campos que ya estoy seguro que no hay nullos... > > >> -- >> Jaime Casanova www.2ndQuadrant.com >> Professional PostgreSQL: Soporte 24x7 y capacitación >> > >>Alvaro Herrera >>Sí, hay varias cosas que son sospechosas en este diseño ... pareciera >>una tabla donde se almacenan detalles crudos (posición geográfica en un >>momento determinado) junto con detalles cocinados (análisis a partir de >>la historia del movimiento del vehículo). Eso deberías evitarlo, porque >>crea todo tipo de problemas. > > > de hecho todo esos datos ya fueron procesados y son guardados como > historicos en esta tabla. Aunque si me puedes decir algun tipo de > problemas que tu consideres se presente en este diseño de tabla lo > tomare en cuenta para una posible reestructuracion... > > > Saludos y gracias por sus consejos, siempre son bienvenidos... > > > > Roberto Campos > - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Ayuda con FULL TEXT SEARCH
Sí, hice la prueba usando 'bilingüe' y FTS no devuelve ningún resultado.
También probé forzando a que ignore el índice como me recomendaste y
devuelve los mismos registros que con el índice.
Saludos!
El 25/07/2011 05:56 p.m., Alvaro Herrera escribió:
Excerpts from Rodolfo Paparás's message of lun jul 25 16:13:01 -0400 2011:
Si ejecuto un ts_debug del campo completo que estoy buscando para uno
de los ejemplos que tiene la palabra "bilingue" pero que FTS no incluye
en sus resultados me encuentra entre otras cosas:
(asciiword,Word, all
ASCII",Biling,{spanish_stem},spanish_stem,{biling})"
(asciiword,Word, all
ASCII",Bilingue,{spanish_stem},spanish_stem,{biling})"
(asciiword,Word, all
ASCII",bilingue,{spanish_stem},spanish_stem,{biling})"
Todo indica que el stem está y FTS lo detecta pero sin embargo el query
SELECT * FROM atributos_contactos WHERE valor_cadena_index @@
to_tsquery('bilingue');
descarta muchos registros.
Con respecto a la palabra "bilingue", es verdad que es un ejemplo
rebuscado, pero estoy buscando en el texto de curriculums personas con
esa capacidad.
Alguna otra idea?
¿Has probado buscando por "bilingüe", que es la forma correcta de
escribir esa palabra?
También prueba con
SET enable_indexscan TO off;
Si después de ese cambio te retorna todos los resultados, el problema
está en el índice GIN.
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Ayuda con FULL TEXT SEARCH
At 22:13 25/07/2011, Rodolfo Paparás wrote:
SELECT * FROM atributos_contactos WHERE
valor_cadena_index @@ to_tsquery('bilingue');
descarta muchos registros.
Con respecto a la palabra "bilingue", es verdad
que es un ejemplo rebuscado, pero estoy buscando
en el texto de curriculums personas con esa capacidad.
Alguna otra idea?
En
http://www.postgresql.org/docs/9.1/static/textsearch-controls.html#TEXTSEARCH-PARSING-QUERIES
viene como incluir los prefijos:
Also, * can be attached to a lexeme to specify prefix matching:
SELECT to_tsquery('supern:*A & star:A*B');
to_tsquery
--
'supern':*A & 'star':*AB
Such a lexeme will match any word in a tsvector
that begins with the given string.
HTH
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Ayuda con FULL TEXT SEARCH
Excerpts from Rodolfo Paparás's message of lun jul 25 16:13:01 -0400 2011:
>Si ejecuto un ts_debug del campo completo que estoy buscando para uno
>de los ejemplos que tiene la palabra "bilingue" pero que FTS no incluye
>en sus resultados me encuentra entre otras cosas:
>
>(asciiword,Word, all
>ASCII",Biling,{spanish_stem},spanish_stem,{biling})"
>(asciiword,Word, all
>ASCII",Bilingue,{spanish_stem},spanish_stem,{biling})"
>(asciiword,Word, all
>ASCII",bilingue,{spanish_stem},spanish_stem,{biling})"
>
>Todo indica que el stem está y FTS lo detecta pero sin embargo el query
>SELECT * FROM atributos_contactos WHERE valor_cadena_index @@
>to_tsquery('bilingue');
>descarta muchos registros.
>Con respecto a la palabra "bilingue", es verdad que es un ejemplo
>rebuscado, pero estoy buscando en el texto de curriculums personas con
>esa capacidad.
>Alguna otra idea?
¿Has probado buscando por "bilingüe", que es la forma correcta de
escribir esa palabra?
También prueba con
SET enable_indexscan TO off;
Si después de ese cambio te retorna todos los resultados, el problema
está en el índice GIN.
--
Álvaro Herrera
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Ayuda con FULL TEXT SEARCH
Si ejecuto un ts_debug del campo completo que estoy buscando para
uno de los ejemplos que tiene la palabra "bilingue" pero que FTS no
incluye en sus resultados me encuentra entre otras cosas:
(asciiword,Word,
all ASCII",Biling,{spanish_stem},spanish_stem,{biling})"
(asciiword,Word, all
ASCII",Bilingue,{spanish_stem},spanish_stem,{biling})"
(asciiword,Word, all
ASCII",bilingue,{spanish_stem},spanish_stem,{biling})"
Todo indica que el stem está y FTS lo detecta pero sin embargo el
query
SELECT * FROM atributos_contactos WHERE valor_cadena_index @@
to_tsquery('bilingue');
descarta muchos registros.
Con respecto a la palabra "bilingue", es verdad que es un ejemplo
rebuscado, pero estoy buscando en el texto de curriculums personas
con esa capacidad.
Alguna otra idea?
Saludos y gracias
El 25/07/2011 03:46 p.m., Alvaro Herrera escribió:
Excerpts from Jaime Casanova's message of lun jul 25 14:29:00 -0400 2011:
Yo partiría por verificar los resultados: primero cuál es el stem (??)
que se está buscando con FTS (prueba ts_debug), segundo ver cuál es el
stem de los términos que se encuentran con LIKE. Ten presente que si la
palabra es babilingue (o cualquier tontera con un prefijo antes de la
palabra), la expresión LIKE lo encontrará pero el FTS no.
yo tuve este mismo problema hace un año cuando quize entender FTS, y
lo postergue hasta tener tiempo... aun esta en mi TODO...
no sabia de ts_debug, voy a ver que me dice... pero me llamo la
atencion lo de las palabras "babilingues" (que aun no se que son) y lo
de palabras con prefijo... porque FTS no puede encontrarlas pero LIKE
si?
No existe babilingues, sólo le puse "ba" al principio (prefijo) de la
palabra para ilustrar mi punto. Creo que habría sido más fácil si
Rodolfo no hubiera usado un ejemplo tan rebuscado.
Pensando en LIKE, la expresión "xxunoxx" LIKE '%uno%' es obviamente
verdadera. Pero FTS no lo encontrará si buscar por to_tsquery('uno')
porque sólo buscará palabras que _empiecen_ con "uno" (o más exactamente,
con el stem de "uno" que supongo que será "un").
Re: [pgsql-es-ayuda] Ayuda con FULL TEXT SEARCH
Excerpts from Jaime Casanova's message of lun jul 25 14:29:00 -0400 2011:
> > Yo partiría por verificar los resultados: primero cuál es el stem (??)
> > que se está buscando con FTS (prueba ts_debug), segundo ver cuál es el
> > stem de los términos que se encuentran con LIKE. Ten presente que si la
> > palabra es babilingue (o cualquier tontera con un prefijo antes de la
> > palabra), la expresión LIKE lo encontrará pero el FTS no.
> yo tuve este mismo problema hace un año cuando quize entender FTS, y
> lo postergue hasta tener tiempo... aun esta en mi TODO...
> no sabia de ts_debug, voy a ver que me dice... pero me llamo la
> atencion lo de las palabras "babilingues" (que aun no se que son) y lo
> de palabras con prefijo... porque FTS no puede encontrarlas pero LIKE
> si?
No existe babilingues, sólo le puse "ba" al principio (prefijo) de la
palabra para ilustrar mi punto. Creo que habría sido más fácil si
Rodolfo no hubiera usado un ejemplo tan rebuscado.
Pensando en LIKE, la expresión "xxunoxx" LIKE '%uno%' es obviamente
verdadera. Pero FTS no lo encontrará si buscar por to_tsquery('uno')
porque sólo buscará palabras que _empiecen_ con "uno" (o más exactamente,
con el stem de "uno" que supongo que será "un").
--
Álvaro Herrera
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Ayuda con FULL TEXT SEARCH
Alvaro:
Antes que nada gracias!
Entiendo lo que decís acerca de que en la condición like
'%cadena_de_texto%' entrarían cosas que el FTS no toma (palabras con
prefijo, etc), pero en este caso y analizando algunos de los resultados
arrojados por el like aparece palabra 'bilingue' y por algún motivo el
FTS no las trae.
El stem en este caso es 'biling' y está en los campos tipo ts_vector de
las filas que analicé y que el FTS no trajo.
Voy a ver que encuentro con el ts_debug.
Saludos
El 25/07/2011 03:01 p.m., Alvaro Herrera escribió:
Excerpts from Rodolfo Paparás's message of lun jul 25 12:48:31 -0400 2011:
SELECT * FROM atributos_contactos WHERE valor_cadena like '%bilingue%';
Por otra parte, si utilizo funcionalidades de FTS y uso como criterio un
campo generado en base al anterior mediante la función to_tsvector
(select to_tsvector('spanish',valor_cadena)) y habiendo generado además
un indice tipo gin para dicho campo, obtengo como resultado solamente 4
líneas en 32 milisegundos.
SELECT * FROM atributos_contactos WHERE valor_cadena_index @@
to_tsquery('bilingue'); --
Yo partiría por verificar los resultados: primero cuál es el stem (??)
que se está buscando con FTS (prueba ts_debug), segundo ver cuál es el
stem de los términos que se encuentran con LIKE. Ten presente que si la
palabra es babilingue (o cualquier tontera con un prefijo antes de la
palabra), la expresión LIKE lo encontrará pero el FTS no.
--
Rodolfo
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Ayuda con FULL TEXT SEARCH
2011/7/25 Alvaro Herrera : > > Yo partiría por verificar los resultados: primero cuál es el stem (??) > que se está buscando con FTS (prueba ts_debug), segundo ver cuál es el > stem de los términos que se encuentran con LIKE. Ten presente que si la > palabra es babilingue (o cualquier tontera con un prefijo antes de la > palabra), la expresión LIKE lo encontrará pero el FTS no. > yo tuve este mismo problema hace un año cuando quize entender FTS, y lo postergue hasta tener tiempo... aun esta en mi TODO... no sabia de ts_debug, voy a ver que me dice... pero me llamo la atencion lo de las palabras "babilingues" (que aun no se que son) y lo de palabras con prefijo... porque FTS no puede encontrarlas pero LIKE si? -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Ayuda con FULL TEXT SEARCH
Excerpts from Rodolfo Paparás's message of lun jul 25 12:48:31 -0400 2011:
> SELECT * FROM atributos_contactos WHERE valor_cadena like '%bilingue%';
>
> Por otra parte, si utilizo funcionalidades de FTS y uso como criterio un
> campo generado en base al anterior mediante la función to_tsvector
> (select to_tsvector('spanish',valor_cadena)) y habiendo generado además
> un indice tipo gin para dicho campo, obtengo como resultado solamente 4
> líneas en 32 milisegundos.
>
> SELECT * FROM atributos_contactos WHERE valor_cadena_index @@
> to_tsquery('bilingue'); --
Yo partiría por verificar los resultados: primero cuál es el stem (??)
que se está buscando con FTS (prueba ts_debug), segundo ver cuál es el
stem de los términos que se encuentran con LIKE. Ten presente que si la
palabra es babilingue (o cualquier tontera con un prefijo antes de la
palabra), la expresión LIKE lo encontrará pero el FTS no.
--
Álvaro Herrera
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] Ayuda con FULL TEXT SEARCH
Hola a todos.
Sería de gran ayuda si alguien me pudieran dar una mano con esto:
Estoy haciendo pruebas con las funcionalidades de búsqueda de texto de
postgres 8.4 y no termino de entender algunos resultados.
Si realizo un query usando el operador like sobre el campo valor_cadena
(que es un campo tipo text) obtengo un resultado de 1358 filas en 5922 ms.
SELECT * FROM atributos_contactos WHERE valor_cadena like '%bilingue%';
Por otra parte, si utilizo funcionalidades de FTS y uso como criterio un
campo generado en base al anterior mediante la función to_tsvector
(select to_tsvector('spanish',valor_cadena)) y habiendo generado además
un indice tipo gin para dicho campo, obtengo como resultado solamente 4
líneas en 32 milisegundos.
SELECT * FROM atributos_contactos WHERE valor_cadena_index @@
to_tsquery('bilingue'); --
Estoy haciendo algo mal? Alguna idea?
Saludos y gracias de antemano
--
Rodolfo
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] datos no coinciden entre master y hot standby
Hola Jaime Entonces solo con la configuración hot standby y wal_keep_segment en el maestro seria suficiente para disponer de una replica de solo lectura para mi base de datos principal!. En un momento dado, si mi base de datos maestro se cae, el hot standby puede entrar a sustituirlo durante la operación (estableciendo el parámetro hot_standby = off y retirando el archivo recovery.conf) y en tiempos muertos, sincronizar el maestro con la carpeta data del esclavo y volviendo a colocar nuevamente todo como en el principio? Le agradezco mucho su repuesta y tiempo. 2011/7/24 Jaime Casanova : > 2011/7/23 Hellmuth Vargas : >> >> Mi >> pregunta es: es necesario configurar ambos (hot standby y replicacion con >> archivelog)? en que casos o situaciones hay que hacerlo? >> > > de hecho estas confundiendo terminos: > > hot standby es tener el servidor de replica configurado para que pueda > contestar consultas de solo lectura y para tenerlo activado debes > estar replicando de algun modo... > > las dos técnicas de replicación integrada que se usan en postgres son: > log shipping (lo que tu llamaste archivelog) y streaming replication. > > ambos son independientes y puedes usar uno sin el otro... la ventaja > de usar ambos juntos es que si apagas el esclavo el maestro seguira > enviando la informacion pendiente hasta que este vuelva a estar > activo, y lo intentara hasta que el segmento de wal sea reutilizado > por postgres (lo cual es algo que no puedes controlar), si tienes > wal_keep_segment garantizas un poco mas de tiempo para que vuelva a la > vida el esclavo a costa de espacio de disco en el servidor... si > tienes log shipping configurado entonces puedes encender tu servidor > cuando desees y te aseguras que la replica buscara ahi los wal que > necesita antes de volver a conectar el streaming desde el maestro > > espero que se entienda > > -- > Jaime Casanova www.2ndQuadrant.com > Professional PostgreSQL: Soporte 24x7 y capacitación > -- Cordialmente, Ing. Hellmuth I. Vargas S. Esp. Telemática y Negocios por Internet Oracle Database 10g Administrator Certified Associate - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] datos no coinciden entre master y hot standby
2011/7/24 Alvaro Herrera : > > Lo que a mí no me queda claro son las garantías cuando tienes log > shipping activado. Yo tenía entendido que si activas log shipping, el > maestro guardará los segmentos de WAL eternamente hasta que el archivado > sea exitoso .. aún si eso causa que el disco se quede sin espacio. ¿Ya > no es así? > con log shipping, si. y si el disco en el que estas archivando se queda sin espacio, el pg_xlog empezará a crecer porque no borrará ningun archivo hasta que este archivado y si el disco donde tienes el pg_xlog se queda sin espacio se te caera la base hasta que liberes espacio (de ambos sitios) > Al final dices que si lo tienes activo puedes encender "tu servidor" > cuando desees. ¿Te refieres al maestro o al esclavo? Si es el esclavo, > ¿no significaría que posiblemente llenarías el disco del maestro si lo > tuvieras apagado mucho tiempo? > si, me referia al esclavo... bueno lo ideal seria que archives el wal en una tercera locacion, asi puedes poner otros nodos que tambien puedan leer de el, si solo tienes dos maquinas es mejor que uses solo wal_keep_segments que guardara solo un numero limitado de segmentos lo malo es que si el SR se atrasa mas alla de ese numero de segmentos te toca reconstruir la replica > -- > Álvaro Herrera > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) > Para cambiar tu suscripción: > http://www.postgresql.org/mailpref/pgsql-es-ayuda > -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
