PlPython es un lenguaje procedural (PL) que permite utilizar Python en una base de datos PostreSQL para poder escribir los procedimientos almacenados. En realidad actualmente es un lenguaje no confiado (untrusted). Se puede leer más aquí: PlPythonu.
Si bien Python maneja listas, diccionarios y otras estructuras de datos con bastante simpleza, no encontramos una manera de hacer casting a un array o vector de PostgreSQL. Particularmente, en el ejemplo debajo, se puede ver que implementamos un wrapper para poder utilizar el motor de expresiones regulares de Python, dentro de la DB, ya que tiene algunas cuestiones más avanzadas que el que trae PgSQL por defecto.
Lo que hicimos fue crear una cadena, con la representación serializada de un Array y dejar que haga el casting PgSQL. Les dejo el código para que lo adapten a sus necesidades. En este caso devuelve un vector de TEXT (TEXT[]) con la idea de emular el resultado devuelto por regexp_matches() en plsql. la signatura de la función es esta:
regexp_python(text,text) RETURNS text[] |
regexp_python(text,text) RETURNS text[]
-- Function: regexp_python(text, text)
-- DROP FUNCTION regexp_python(text, text);
CREATE OR REPLACE FUNCTION regexp_python(p_str text, p_ereg text)
RETURNS TEXT[] AS
$BODY$import re
import string
m = re.search(p_ereg, p_str,re.I)
IF m IS None:
RETURN None
ELSE:
RETURN ('{"'+'","'.join([re.escape(x) FOR x IN m.groups('NULL')])+'"}').REPLACE('"NULL"','NULL')$BODY$
LANGUAGE 'plpythonu' VOLATILE
COST 100;
ALTER FUNCTION regexp_python(text, text) OWNER TO postgres; |
-- Function: regexp_python(text, text)
-- DROP FUNCTION regexp_python(text, text);
CREATE OR REPLACE FUNCTION regexp_python(p_str text, p_ereg text)
RETURNS TEXT[] AS
$BODY$import re
import string
m = re.search(p_ereg, p_str,re.I)
if m is None:
return None
else:
return ('{"'+'","'.join([re.escape(x) for x in m.groups('NULL')])+'"}').replace('"NULL"','NULL')$BODY$
LANGUAGE 'plpythonu' VOLATILE
COST 100;
ALTER FUNCTION regexp_python(text, text) OWNER TO postgres;
Los arrays en PgSQL son serializados como una colección de datos entre llaves:
{‘text1′,’text2’}.
Gracias Milton y Daiana por investigar y aplicar todas estas cosas conmigo 😉
Este es un mini post, para tenerlo a mano y que alguno que busque lo encuentre. Postgresql en los escenarios que la he probado, ha resultado más lenta que MySQL usando MyISAM e InnoDB. Por supuesto esto con la configuración que trae de base en una instalación Debian, Ubuntu o con el instalador (con perfiles) en Windows. O modificándole muy pocos parámetros.
Hace un tiempo ya que para un trabajo que estamos haciendo buscábamos la forma de acelerar los updates en Postgres. No es que fuera algo intolerable, pero a veces necesitabamos correr varias consultas que actualizaban unos 2M registros en base a si cumplían o no unas 40 expresiones regulares bastante complejas.
Bueno, me dirán, por qué no usaste MySQL entonces. Bueno, porque no je. En realidad porque en cuanto a extensibilidad usando los lenguajes en Postgres (plpythonu, plpgsql,plphp y quizá pljava) teníamos más flexibilidad. Tenía mejores capacidades de gestión de expresiones regulares y posibilidad de usar tipos de datos vectores (para los matching de las reg. exp.).
El post corto se está alargando y me voy a explayar en otros. Lo que intentamos fue meter commits entre medio de los updates, pero de nada servía. Incluso encerrar en una transacción varios updates. Tampoco.
Leyendo encontré que tiene que ver en la performance de PgSQL las copias que se genera de cada tabla que se está accediendo para mantener consistencia en cuanto a las consultas d ediferentes usuarios. Los checkpoints que va haciendo en el log (log de transacciones, no el log de errores) del sistema son los que estaban afectando. En definitiva aumentando el tamaño de los segmentos de los checkpoints debería haber una mejora en performance.
Este parámetro se cambia en
/etc/postgresql/8.3/main/postgresql.conf
checkpoint_segments = 256
Si hubiese mirado el log (avisos y errores) de PgSQL quizá me hubiese dado cuenta. Se la pasaba imprimiendo:
2009-02-10 11:23:09 ARST LOG: los checkpoints están ocurriendo con demasiada frecuencia (cada 2 segundos)
2009-02-10 11:23:09 ARST HINT: Considere incrementar el parámetro de configuración «checkpoint_segments».
Prometo en otro post contar los resultados y ordenar esto.
Fuentes:
http://pugs.postgresql.org/node/499
http://www.linux-es.org/node/660
Por qué: http://www.network-theory.co.uk/docs/postgresql/vol1/Increasecheckpoint_segments.html
http://archives.postgresql.org/pgsql-performance/2008-06/msg00119.php
