Sobrecarga de linguagens processuais do PostgreSQL (plpython / plsql / pllua…)

Estou tentando encontrar informações sobre as funções definidas pelo usuário do PostgreSQL no desempenho de linguagens procedurais para tarefas em tempo real.

1. Como eles se comparam às funções internas?
2. Existe alguma diferença (no overhead) como o Postgres chama / gerencia as funções plpython vs plpgsql vs pllua (estou interessado no lado de integração / contexto / transferência de dados do Postgres, e não na própria VM)?
3. O contexto é uma grande sobrecarga? Posso usá-lo para mapeamento de dados em tempo real (digamos 1000 consultas / s))
4. Existe algum benefício em escrever funções definidas pelo usuário no plpgsql e em outras páginas / linguagem? Na documentação, eles enumeram vantagens, mas acho que se aplicam a todas as linguagens processuais do postgresql.

Resultados relacionados:

• Uma velocidade de linguagens PL para uso atípico
• Desempenho da linguagem das funções do PostgreSQL: C vs PL / PGSQL

1. UDFs em linguagens interpretadas são praticamente sempre mais lentas que UDFs escritas em C ou funções internas, sendo todas as outras coisas iguais.

2. Cada ligação de idioma possui um código diferente para conectar o PostgreSQL à linguagem, com diferentes graus de otimização, diferentes maneiras de passar alguns tipos de dados, etc. Portanto, a variação certamente existe. Não deve ser enorme, a menos que você esteja passando um tipo de dados que obtém tratamento muito diferente em um idioma que outro, por exemplo, um passa a hstorecomo uma string e outro o converte em a dict.

3. Não está claro o que é "o contexto". Você pode usá-lo para "mapeamento de dados em tempo real" ... bem, depende do que a função faz e se é rápida o suficiente no servidor em que está sendo executado, para os clientes para os quais está levando e para os seus requisitos. Quanto tempo dura um pedaço de barbante? Referência.

4. O PL / PgSQL é mais simples de escrever e oferece acesso mais rápido ao SQL. Geralmente é melhor quando você precisa envolver um pouco de lógica em torno de muito SQL. É muito lento para operações matemáticas e algoritmos complexos, portanto, o código puramente computacional no PL / PgSQL deve ser evitado sempre que possível em favor de C ou uma linguagem processual mais rápida.

Acelerações ao reimplementar o código PL / PgSQL em C podem variar de negligenciável a mais de 1000 vezes. Tudo depende do que o código está realmente fazendo.

(Esse tipo de pergunta múltipla não é adequado para o Stack Exchange, pois é mais difícil ter uma resposta definitiva)

isso é bem difícil de dizer. realmente depende do que você está fazendo. por exemplo: PL / pgSQL é maravilhoso se você tiver grandes instruções SQL - realmente ficará louco se você tiver todos os tipos de ramificação, gerenciamento de substring e tudo mais.

você realmente tem que testar caso a caso.

O contexto é uma grande sobrecarga? Posso usá-lo para mapeamento de dados em tempo real (digamos 1000 consultas / s))

O desempenho depende do hardware e da complexidade de suas funções. Criei um dispositivo que rodava em um pequeno servidor de 12 núcleos e um cartão FusionIO (custa 10000 euros no total) e fazia cerca de 2500 transações por segundo com 20 usuários simultâneos. Cada transação chama 29 procedimentos armazenados para processar os dados e retornar algumas informações úteis ao cliente. Algumas funções executam apenas uma consulta, outras, algumas. No total, ele executa cerca de 200000 instruções INSERT, SELECT e UPDATE por segundo.

Tudo isso está escrito em PL / SQL, PL / pgSQL e PL / PerlU. E tenho certeza de que o sistema pode funcionar ainda mais rápido quando (algumas) funções são reescritas em C.

Neste dispositivo, a maioria do desempenho vem do cartão SSD. Em um único disco rotativo, nunca obteríamos esse desempenho. As unidades SSD baratas também falham, funcionam por uma hora (por causa do armazenamento em cache da placa de ataque) e depois termina o jogo. A placa FusionIO é cara, mas é um investimento muito bom quando você está vinculado à IO.