Re: regexp en pgsql

From: Marcos Ortiz <mlortiz(at)uci(dot)cu>
To: Gino Rojas Tillemann <gino(at)masnet(dot)cl>
Cc: Juan <smalltalker(dot)marcelo(at)gmail(dot)com>, Anthony <asotolongo(at)uci(dot)cu>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: regexp en pgsql
Date: 2011-06-28 21:21:44
Message-ID: 4E0A45E8.9050001@uci.cu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

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 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
A mi entender, lo veo muy alto
> wal_buffers = 128
> checkpoint_segments = 256
> shared_buffers = 1920MB
É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.
Algunas cosas de las que pudieras hacer (hazlas sólo si sabes lo que
estás haciendo):
en el /boot/loader.conf, necesitas incrementar el número de semáforos
SysV IPC
kern.ipc.semmni=512
kern.ipc.semmns=1024

Ahora, en el /etc/sysctl.conf, debes incrementar el valor de los tamaños
de la memoria compartida:
kern.ipc.shmmax=4089446400
Éste es el máximo valor del tamaño de un segment de memoria compartida
en bytes

kern.pic.shmall=1050000

Éste es el máximo valor de memoria permitido a ser usado como la memoria
compartida de SysV, en páginas de 4 Kb
En el caso de que la base de datos contenga muchos objetos (díganse
tablas, índices, etc), debes incrementar el máximo
número de archivos abiertos en memoria para la cache de la lista de
directorios:
kern.maxfiles=16384
vfs.ufs.dirhash_maxmem=4194304 (en caso de que estés usando UFS como
sistema de ficheros) Para bases de datos
muchos recomiendan ZFS
Puedes guiarte por la guia propuesta acá
http://solarisinternals.com/ZFSforDatabases
>
>
> El 28 de junio de 2011 16:22, Juan <smalltalker(dot)marcelo(at)gmail(dot)com
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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
>> <mailto: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 <mailto: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

--
Marcos Luís Ortíz Valmaseda
Software Engineer (UCI)
http://marcosluis2186.posterous.com
http://twitter.com/marcosluis2186

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Gino Rojas Tillemann 2011-06-28 21:33:37 Re: regexp en pgsql
Previous Message felix gonzales 2011-06-28 21:05:27 procesos ocupan el total de la RAM