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 :( tendré el mismo problema si levanto una DB de pgsql en EC2 de amazon? mejorarán los procesos desde el cloud de amazon? gracias El 28 de junio de 2011 16:08, Juan <[email protected]> escribió: > 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 <[email protected]> > >> 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/28 Gino Rojas Tillemann <[email protected]> >> >>> 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 fn, es por eso que busco que el proceso se haga mas rápido desde el >>> procesador, lamentablemente postgresql solo me entrega un core del CPU para >>> realizar este trabajo, si tan solo usara los 2 CPU y sus 8 nucleos sería >>> maravilloso :) >>> >>> >>> >>> El 28 de junio de 2011 15:56, Anthony <[email protected]> escribió: >>> >>> ** >>>> 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 >>>> resultados con el procesamiento del texto. >>>> >>>> alguna otra idea? >>>> sld2 >>>> >>>> El 28 de junio de 2011 15:41, Juan <[email protected]>escribió: >>>> >>>>> 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 >>>>> 10000 ; >>>>> eso generalmente acelera las cosas. >>>>> salvo claro esta q ya lo tengas >>>>> salu2 >>>>> mdc >>>>> >>>>> >>>>> 2011/6/28 Gino Rojas Tillemann <[email protected]> >>>>> >>>>>> 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 registro; para lograr esto creé una función en >>>>>> plpgsql con (de momento) 40 expresiones regulares (en algunos casos >>>>>> bastante >>>>>> complejas) y actualizo un campo de una tabla con el resultado del >>>>>> proceso, >>>>>> algo como esto: >>>>>> >>>>>> update my_table set campo_final=fn_regexp(campo1||campo2||campo3) >>>>>> where id between 1 and 10000 >>>>>> >>>>>> la función "fn_regexp" contiene la lógica de las expresiones >>>>>> regulares y la tabla my_table es de 32 millones de registros >>>>>> >>>>>> si alguien tiene alguna idea de como optimizar la ejecución de las >>>>>> expresiones regulares será de gran ayuda, gracias.. >>>>>> >>>>>> haaa y por fa no me sugieran crear varios threads con otro lenguaje >>>>>> ya que lo que busco es bajar mis actuales 7 minutos de proceso >>>>>> >>>>>> >>>>>> saludos >>>>>> >>>>>> -- >>>>>> Gino Rojas Tillemann >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Gino Rojas Tillemann >>>> >>>> tienes algún criterio que te pueda servir para particionar la tabla? >>>> pues el particioamiento te puede ayudar. >>>> saludos >>>> >>> >>> >>> >>> -- >>> Gino Rojas Tillemann >>> >> >> > -- Gino Rojas Tillemann
