Sobrecarga de lenguajes de procedimiento PostgreSQL (plpython / plsql / pllua ...)

Estoy tratando de encontrar información sobre las funciones definidas por el usuario de PostgreSQL en el rendimiento de los lenguajes de procedimiento para tareas en tiempo real.

1. ¿Cómo se comparan con las funciones integradas?
2. ¿Hay alguna diferencia (en gastos generales) en cómo Postgres llama / gestiona plpython vs plpgsql vs pllua (estoy interesado en el lado de integración / contexto / transferencia de datos de Postgres, no en la VM en sí)?
3. ¿Es el contexto una gran sobrecarga? ¿Puedo usarlo para el mapeo de datos en tiempo real (digamos 1000 consultas / s))
4. ¿Hay algún beneficio de escribir funciones definidas por el usuario en plpgsql y luego en otro pg / idioma? En la documentación enumeran ventajas, pero creo que se aplican a todos los lenguajes de procedimiento postgresql.

Hallazgos relacionados:

• Una velocidad de idiomas PL para uso atípico
• Rendimiento del lenguaje de funciones PostgreSQL: C vs PL / PGSQL

1. Las UDF en lenguajes interpretados son casi siempre más lentas que las UDF escritas en C o funciones integradas, todas las demás cosas son las mismas.

2. Cada enlace de idioma tiene un código diferente para conectar PostgreSQL al idioma, con diferentes grados de optimización, diferentes formas de pasar algunos tipos de datos, etc. Por lo tanto, ciertamente existe variación. No debería ser enorme a menos que esté pasando un tipo de datos que recibe un manejo muy diferente por un idioma que otro, por ejemplo, uno pasa un hstorecomo una cadena y otro lo convierte en un dict.

3. No está claro cuál es "el contexto". ¿Puede usarlo para el "mapeo de datos en tiempo real"? Bueno, depende de lo que haga la función y si es lo suficientemente rápida en el servidor en el que se está ejecutando, para los clientes a los que se dirige y para sus requisitos. ¿Que tan larga es una pieza de cordon? Punto de referencia.

4. PL / PgSQL es más sencillo de escribir y ofrece un acceso más rápido a SQL. En general, es mejor cuando necesita ajustar un poco de lógica alrededor de una gran cantidad de SQL. Es muy lento para operaciones matemáticas y algoritmos complejos, por lo que se debe evitar el código puramente computacional en PL / PgSQL siempre que sea posible a favor de C, o un lenguaje de procedimiento más rápido.

Las aceleraciones al volver a implementar el código PL / PgSQL en C pueden variar de insignificante a más de 1000 veces. Todo depende de lo que el código esté haciendo realmente.

(Este tipo de preguntas múltiples no es adecuado para Stack Exchange, ya que es más difícil tener una respuesta definitiva)

Esto es bastante difícil de decir. realmente depende de lo que estés haciendo. por ejemplo: PL / pgSQL es maravilloso si tiene grandes sentencias SQL en él; realmente se vuelve loco si tiene todo tipo de ramificación, administración de subcadenas y todo eso.

realmente tienes que probar de un caso a otro.

¿Es el contexto una gran sobrecarga? ¿Puedo usarlo para el mapeo de datos en tiempo real (digamos 1000 consultas / s))

El rendimiento depende del hardware y la complejidad de sus funciones. Creé un dispositivo que funcionaba en un pequeño servidor de 12 núcleos y una tarjeta FusionIO (costo total de 10000 euros) e hice alrededor de 2500 transacciones por segundo con 20 usuarios concurrentes. Cada transacción requiere 29 procedimientos almacenados para procesar los datos y devolver cierta información útil al cliente. Algunas funciones ejecutan solo una consulta, otras un par de consultas. En total, ejecuta aproximadamente 200000 instrucciones INSERT, SELECT y UPDATE por segundo.

Todo esto está escrito en PL / SQL, PL / pgSQL y PL / PerlU. Y estoy bastante seguro de que el sistema puede ejecutarse aún más rápido cuando (algunas) funciones se reescriben en C.

En este dispositivo, la mayor parte del rendimiento proviene de la tarjeta SSD. En un solo disco giratorio, nunca obtendríamos este rendimiento. Las unidades SSD baratas también fallan, funciona durante una hora (debido al almacenamiento en caché de la tarjeta de banda) y luego se termina el juego. La tarjeta FusionIO es costosa, pero es una muy buena inversión cuando estás obligado a hacer IO.