[pyar] conexion de python con postgres ¿que me recomiendan?

Claudio Freire klaussfreire en gmail.com
Sab Sep 10 20:17:30 ART 2011


2011/9/11 Mariano Reingart <reingart en gmail.com>:
> Depende, con ese criterio haría la aplicación directamente en C.
> En el contexto de una webapp no creo que haga diferencia.
> pg8000 usa socket, ssl y struct, asique a mi entender esta bastante
> optimizado usando bibliotecas en C.
> Obviamente psycopg2 debería ser más rápido (tendría que probar para
> saber cuanto...) pero no creo que haga diferencia respecto a los otros
> tiempos que se manejan (de pg mismo y el interprete de python).
>
> Si se manejan muchos datos, yo directamente usaría COPY y los
> procesaría dentro del servidor con algún lenguaje procedural (plpgsql,
> plpython o funciones en C llegado el caso).

Cuando manejás muchos datos, ni struct ni socket te ayudan.
Struct involucra muchísimas copias, de cadenas, de valores. Todo eso
en C se logra con un simple cast, que es un truco del compilador que
requiere 0 ciclos de procesador. Es decir, python es infinitamente más
lento en interpretar cadenas como estructuras, pues en C no hace falta
hacer nada, mientras que en python hace falta hacer mucho (llamar a
struct y crear los objetos int, incluso uno, es mucho en comparación).

Copy no te ayuda. Copy no sirve para nada excepto tareas triviales de
carga o dump de datos.

> Igualmente, probé los test contra pg9 y funcionan, por curiosidad,
> ¿que error tuviste?

Se me fue realmente de la cabeza. Sólo recuerdo que se conectaba
(funcionaba) con el protocolo viejo, que no soportaba un feature que
queríamos usar (que no recuerdo cuál). Hacer que lo soporte fue tan
sencillo como recompilar psycopg2 con la nueva libpq.

No era un feature invocable, era creo un formato de transferencia
diferente. Oh, ahí recordé:

"All messages now have a length count immediately following the
message type byte (except for startup packets, which have no type
byte). Also note that PasswordMessage now has a type byte."

Eso nos permitía pasar por un pooler customizado nuestro que parseaba
muy poco del protocolo, sólo lo suficiente como para decidir si mandar
al master o a un slave.



More information about the pyar mailing list