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

[Mariano Reingart]

2011/9/10 Claudio Freire <klaussfreire en gmail.com>:
> 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).

Ok, no te lo discuto, no me estas leyendo todo el mail, lo digo en el
contexto de una webapp, que creo que es suficiente, nada más.

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

Disiento, una de las tareas mas lentas es subir datos, y COPY es
varios ordenes de magnitud mas rápido que INSERT (con tiempo podría
dar ejemplos).

Además decía que se pueden usar funciones (procedimientos almacenados)
dentro de postgresql para procesar datos (incluso con plpython, sin
usar siquiera libpq ni transmitirlos por la red,y no hace falta COPY
tampoco).

>> 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.

Interesante.

Igualmente voy a armar un par de benchmarks para ver cuanta diferencia hay.

YMMV

Sds

Mariano Reingart
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com