Estou tentando encontrar informações sobre funções definidas pelo usuário do PostgreSQL no desempenho de linguagens procedurais para tarefas em tempo real.
- Como eles se comparam às funções internas?
- Existe alguma diferença (em sobrecarga) como o Postgres chama / gerencia as funções plpython vs plpgsql vs pllua (estou interessado no lado da integração / contexto / transferência de dados do Postgres, não na própria VM)?
- O contexto é uma grande sobrecarga? Posso usá-lo para mapeamento de dados em tempo real (digamos 1000 consultas/s))
- Existe algum benefício em escrever funções definidas pelo usuário em plpgsql e depois em outro pg/idioma? Na documentação eles enumeram vantagens, mas acho que se aplicam a todas as linguagens procedurais do postgresql.
Descobertas relacionadas:
UDFs em linguagens interpretadas são quase sempre mais lentas do que UDFs escritas em C ou funções internas, todas as outras coisas sendo as mesmas.
Cada ligação de linguagem tem um código diferente para conectar o PostgreSQL à linguagem, com diferentes graus de otimização, diferentes formas de passar alguns tipos de dados, etc. Portanto, certamente existe variação. Não deve ser enorme, a menos que você esteja passando um tipo de dados que recebe tratamento muito diferente de um idioma para outro, por exemplo, um passa
hstorecomo uma string e outro o converte em umdict.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ápido o suficiente no servidor em que está sendo executado, para os clientes que está atendendo e para seus requisitos. Quanto mede um pedaço de barbante? Referência.
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, então código puramente computacional em PL/PgSQL deve ser evitado sempre que possível em favor de C, ou uma linguagem procedural mais rápida.
Os aumentos de velocidade ao reimplementar o código PL/PgSQL em C podem variar de insignificante a mais de 1.000 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)
O desempenho depende do hardware e da complexidade de suas funções. Eu criei um dispositivo que rodava em um pequeno servidor de 12 núcleos e um cartão FusionIO (custo total de 10.000 euros) e fazia cerca de 2.500 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 consultas. No total, ele executa cerca de 200.000 instruções INSERT, SELECT e UPDATE por segundo.
Tudo isso é escrito em PL/SQL, PL/pgSQL e PL/PerlU. E tenho certeza de que o sistema pode rodar ainda mais rápido quando (algumas) funções são reescritas em C.
Neste dispositivo, a maior parte do desempenho vem da placa SSD. Em um único disco giratório, nunca obteríamos esse desempenho. Unidades SSD baratas também falham, funcionam por uma hora (por causa do cache do cartão de invasão) e então o jogo acaba. O cartão FusionIO é caro, mas um investimento muito bom quando você está vinculado a IO.
isso é muito difícil de dizer. realmente depende do que você está fazendo. por exemplo: PL/pgSQL é maravilhoso se você tiver grandes instruções SQL nele - é realmente louco se você tiver todos os tipos de ramificação, gerenciamento de substring e tudo mais.
você realmente tem que testar caso a caso.