Wed, Jun 29, 2011 at 11:16:51AM -0400, Alvaro Herrera escribió:
>
>Si los tiempos son muy altos, siempre hay algo que optimizar para
>mejorarlos. Quizás es hardware (i.e. más cores) o quizás es cambiar la
>lógica del sistema, quizás es rediseñar todo. Yo honestamente sospecho
>que tu diseño de l
Gino
si la que usas esta en C no creo q pueda ser mejorada la velocidad de
ejecucion en tal caso podrias probarlo ( testearlo) sin involucrar a tu
programa.
o sea tomas 10.000 regex y tomas cuanto le toma procesarlas el plperl
tomas 10.000 regex y tomas cuanto le toma procesarlas el C
pero no creo
Juan, especular que tengo un problema de diseño está fuera del foco de este
cable, lo único que necesitaba saber, era como mejorar el tiempo de proceso
de una function que procesa un texto con 40 expresiones regulares,
independiente si el resultado se guarda en la DB o en un archivo de texto.
Ayer
Gino
Una duda ya que hablan de diseño. porque actualizar todos los campos con una
regex y no usar un trigger? asi se distribuye el tiempo y no se vuelve un
cuello de botella-
salu2
mdc
2011/6/29 Gino Rojas Tillemann
> argumentar que llevo varios años modelando base de datos oracle, postgresql
argumentar que llevo varios años modelando base de datos oracle, postgresql
y otras $más no viene al caso, pero si puedo decir que he puesto toda la
experiencia posible en diseñar un modelo optimo para mis requerimientos,
aunque sé que siempre es posible mejorar las cosas y es lo que quiero hacer;
Excerpts from Gino Rojas Tillemann's message of mié jun 29 12:30:48 -0400 2011:
> Gracias Álvaro, tomaré unas clases de programación para solucionar mi
> problema ;)
No, yo ya sé que como programador tienes mucha experiencia. Pero no sé
como diseñador de BDs, y particularmente en Postgres. Es fá
Gracias Álvaro, tomaré unas clases de programación para solucionar mi
problema ;)
---
Jaime, Ahora estoy haciendo las primeras pruebas con plperl y de momento ha
funcionado mejor que con plpgsql
apenas tenga los tiempos reales les cuento,
Gracias Jaime
El 29 de junio de 2011 11:16, Alvaro Herr
Excerpts from Gino Rojas Tillemann's message of mar jun 28 18:00:02 -0400 2011:
> si,
> tengo 8 cores en total, así que para utilizar el 99% de cada uno, desde c#
> envío 8 threads con distintas conexiones, lo cual me permite procesar 80 mil
> registros en 7 minutos, y eso es lo único que tengo
esta respuesta me gustó :)
tenía la idea de que plpgsql era más rápido, incluso estaba creando una en C
para probar la velocidad..
voy a crear la función ahora y ver que tanto puede mejorar con plperl
gracias!
El 28 de junio de 2011 19:05, Jaime Casanova escribió:
> Gino Rojas Tillemann write
Gino Rojas Tillemann writes:
> Hola a todos,
>
> hace un par de semanas estoy peleando con mi DB y las expresiones regulares,
> cada vez que proceso 10 mil registros de un universo de 32 millones el motor
> demora 7 minutos pegados sin variación en procesar una cadena de texto por
> cada regis
si,
tengo 8 cores en total, así que para utilizar el 99% de cada uno, desde c#
envío 8 threads con distintas conexiones, lo cual me permite procesar 80 mil
registros en 7 minutos, y eso es lo único que tengo
la verdad es que imagine que podría, de alguna manera, decirle al postgresql
que utili
Excerpts from Gino Rojas Tillemann's message of mar jun 28 17:43:16 -0400 2011:
> Álvaro ocurre que no comprendiste bien la pregunta que te hice ese día, mi
> aplicación ya procesa con threadsla pregunta era si es posible que el motor
> de base de datos utilizara todos sus cores para realizar una o
Álvaro ocurre que no comprendiste bien la pregunta que te hice ese día, mi
aplicación ya procesa con threadsla pregunta era si es posible que el motor
de base de datos utilizara todos sus cores para realizar una operación, nada
mas..
y como tu respuesta fue "NO" pensé es escribir a la comunidad
e
Excerpts from Marcos Ortiz's message of mar jun 28 17:21:44 -0400 2011:
> Éste pudieras subir a 2048 Mb, en caso de que tu FreeBSD 8.2 sea de 64
> bits (altamente recomendado)
> Recuerda también tunear el sistema operativo, si es un servidor dedicado
> a PostgreSQL.
... otros consejos ...
Nada
Hola Marco voy a revisar mis parámetros de acuerdo a los tuyos, de todas
maneras pego nuevamente la config de mi servidor con todos los archivos de
config.
Servidor dedicado únicamente como base de datos.
Server HP ML150 G6 (2 CPUS)
1.- XEON E5504 2.0GHz 4 cores
2.- XEON E5504 2.0GHz 4 cores
8GB
El 6/28/2011 4:41 PM, Gino Rojas Tillemann escribió:
Mi hardware es el siguiente:
Server HP ML150 G6 (2 CPUS)
1.- XEON E5504 2.0GHz 4 cores
2.- XEON E5504 2.0GHz 4 cores
8GB de RAM KINGSTON 2GB KTH-PL313/2G Unbuffered Advanced ECC memory
Controlador STD HP Smart Array P410 controller w/ Zero M
Mi hardware es el siguiente:
Server HP ML150 G6 (2 CPUS)
1.- XEON E5504 2.0GHz 4 cores
2.- XEON E5504 2.0GHz 4 cores
8GB de RAM KINGSTON 2GB KTH-PL313/2G Unbuffered Advanced ECC memory
Controlador STD HP Smart Array P410 controller w/ Zero Memory cache Raid
Controller (RAID 0,1, 0+1)
3 Discos HDD
No sabria decirte.
proba copiar una cantidad menor de registros asi la variable cantidad de
registros desaparece.
Otra es como tenes configurado el postgres y en que fierro corre.
publica tu postgres.conf y la configuracion de hasrdware
Alvaro , y otros podran decirte q parametro de configuracion
n
lamentablemente la función hace lo que tiene que hacer y ya se ha optimizado
bastante, aunque no sé si en regexp \d es mas rápido que [0-9], cosas como
esas no las he probado.
tal parece que no hay forma de optimizar eso desde el motor creo que tendré
que asumir el tiempo de proceso de la función
Gino gente ,
Perdon se me escapo sin terminar el correo.
Fijate entonces como optimizar si es posible la expresion en si misma
sino podes crear expresiones q funcionen pero q sean lentas.
salu2
mdc
2011/6/28 Juan
> Gino
>
> Entonces y si las regexp estan compiladas en C no creo q haya manera de
Gino
Entonces y si las regexp estan compiladas en C no creo q haya manera de
mejorar la velocidad.
Las expresiones regulares la sintax es importante y existen muchas formas de
mejorar la busqueda.
Si no estas muy experto en ellas es posible construir expresiones regulares
poco eficientes
2011/6/
el campo id ya esta indexado y no se trata de la cantidad de registros que
tenga la tabla, probé moviendo 10 mil registros a una tabla nueva y demora
lo mismo, solo cambia los tiempos de proceso cuando quito expresiones
regulares de la función, pero lamentablemente no puedo quitar esas regexp de
la
On 28/06/11 15:48, Gino Rojas Tillemann wrote:
Hola Juan, si hago eso tendría que crear 3.200 indices para esa tabla,
ademas no necesariamente voy a actualizar el registros 1 al 10mil
podría ser del 8mil al 15mil etc...
ahora voy a crear la misma función en C para ver si así logro mejores
res
entonces no le pongas el where. pero indice en una tabla tan grande por
campo de
busqueda tenes q tener si queres q no tarde demasiado
proque no probas con
explain analyze 'tu querie'
a ver q te meustra el plan.
salu2
mdc
2011/6/28 Gino Rojas Tillemann
> Hola Juan, si hago eso tendría que crea
Hola Juan, si hago eso tendría que crear 3.200 indices para esa tabla,
ademas no necesariamente voy a actualizar el registros 1 al 10mil podría ser
del 8mil al 15mil etc...
ahora voy a crear la misma función en C para ver si así logro mejores
resultados con el procesamiento del texto.
alguna otra
Hola gente
Gino por lo que veo en tu query te convendria tener un index en la expresion
where
o sea my_table tenga un index con where .
o mejor.
create index my_nombre_de_index on mytable( id ) where id between 1 and
1 ;
eso generalmente acelera las cosas.
salvo claro esta q ya lo tengas
salu2
26 matches
Mail list logo
