Re: regexp en pgsql

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 146GB 15K SAS 3.5 DUAL PORT hot-swap - SAS - 15000 rpm
Tarjeta de memoria para la controladora - HP 256MBP-SERIESCACHEUPGRADE
Sistema operativo FreeBSD 8.2
PostgreSQL 9.0

Mi postgresql.conf

listen_addresses = '*'
port = 5432
max_connections = 100
temp_buffers = 8MB
cpu_tuple_cost = 0.0030
cpu_index_tuple_cost = 0.0010
cpu_operator_cost = 0.0005
fsync = off
checkpoint_timeout = 1h
maintenance_work_mem = 480MB
checkpoint_completion_target = 0.9
effective_cache_size = 5632MB
work_mem = 80MB
wal_buffers = 128
checkpoint_segments = 256
shared_buffers = 1920MB

El 28 de junio de 2011 16:22, Juan <smalltalker(dot)marcelo(at)gmail(dot)com> escribió:

> 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
> no esta bueno
> sal2
>
> mdc
>
> 2011/6/28 Gino Rojas Tillemann <gino(at)masnet(dot)cl>
>
>> 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 <smalltalker(dot)marcelo(at)gmail(dot)com>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 <smalltalker(dot)marcelo(at)gmail(dot)com>
>>>
>>>> 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 <gino(at)masnet(dot)cl>
>>>>
>>>>> 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 <asotolongo(at)uci(dot)cu> 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 <smalltalker(dot)marcelo(at)gmail(dot)com>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 <gino(at)masnet(dot)cl>
>>>>>>>
>>>>>>>> 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
>>
>
>

--
Gino Rojas Tillemann