Como comparar o desempenho do PostgreSQL

• Como comparar o PostgreSQL
• Quais são os principais fatores de desempenho no PostgreSQL
• Quais são as alavancas que você pode usar para aumentar o desempenho
• Quais são as armadilhas de desempenho a serem evitadas
• Quais são os erros comuns que as pessoas cometem?
• Como você sabe se o seu sistema está funcionando? Quais ferramentas você pode usar?

Como comparar o PostgreSQL

Especificações da máquina

-bash-4.1$ ./pgbench -i -p 5432 -d postgres
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables…
100000 of 100000 tuples (100%) done (elapsed 0.18 s, remaining 0.00 s)
Vacuum…
set primary keys…
done.

-bash-4.1$ ./pgbench -c 10
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 100/100
latency average = 13.516 ms
tps = 739.865020 (including connections establishing)
tps = 760.775629 (excluding connections establishing)

• Que tipo de carga de trabalho?
• Quantas sessões simultâneas?
• Qual ​​é o conjunto médio de resultados de consultas?
• Quais são os tps (transação por segundo) esperados?

-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15741
latency average = 1916.650 ms
tps = 52.174363 (including connections establishing)
tps = 52.174913 (excluding connections establishing)
-bash-4.1$

-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15215
latency average = 1984.255 ms
tps = 68.396758 (including connections establishing)
tps = 68.397322 (excluding connections establishing)

-bash-4.1$ cat /tmp/bench.sql 
INSERT INTO test_bench VALUES(1,'test');
INSERT INTO test_bench VALUES(1,'test');
SELECT * FROM test_bench WHERE id=1;
SELECT * FROM test_bench WHERE id=2;
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n -f /tmp/bench.sql 
transaction type: multiple scripts
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 25436
latency average = 1183.093 ms
tps = 84.524217 (including connections establishing)
tps = 84.525206 (excluding connections establishing)
SQL script 1: <builtin: select only>
 - weight: 1 (targets 50.0% of total)
 - 12707 transactions (50.0% of total, tps = 42.225555)
 - latency average = 914.240 ms
 - latency stddev = 558.013 ms
SQL script 2: /tmp/bench.sql
 - weight: 1 (targets 50.0% of total)
 - 12729 transactions (50.0% of total, tps = 42.298662)
 - latency average = 1446.721 ms
 - latency stddev = 765.933 ms

Quais são os principais fatores de desempenho no PostgreSQL

• Carga de trabalho
• Recurso
• Otimização
• Contenção

O que são dicas e práticas recomendadas

• Você pode considerar a execução de atividades de manutenção como VACUUM e ANALYZE após uma grande modificação em seu banco de dados. Isso ajuda o planejador a criar o melhor plano para executar as consultas.
• Procure qualquer necessidade de indexar tabelas. Isso torna as consultas muito mais rápidas, em vez de ter que fazer verificações de tabela completas.
• Para tornar uma travessia de índice muito mais rápida, você pode usar os comandos CREATE TABLE AS ou CLUSTER para agrupar linhas com valores de chave semelhantes.
• Quando você encontrar um problema de desempenho, use o comando EXPLAIN para ver o plano de como o otimizador decidiu executar sua consulta.
• Você pode tentar alterar os planos influenciando o otimizador modificando os operadores de consulta. Por exemplo, se você vir uma verificação sequencial para sua consulta, poderá desabilitar a verificação seq usando "SET ENABLE_SEQSCAN TO OFF". Não há garantia de que o otimizador não escolheria esse operador se você desativá-lo. O otimizador apenas considera o operador muito mais caro. Mais detalhes estão aqui:https://www.postgresql.org/docs/current/static/runtime-config-query.html
• Você também pode tentar alterar os parâmetros de custos como CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST e EFFECTIVE_CACHE_SIZE para influenciar o otimizador. Mais detalhes estão aqui:https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
• Sempre filtre os dados no servidor e não no aplicativo cliente. Isso minimizará o tráfego de rede e proporcionará melhor desempenho.
• Para realizar operações comuns, é sempre recomendável usar procedimentos do lado do servidor (gatilhos e funções). Os acionadores ou funções do lado do servidor são analisados, planejados e otimizados na primeira vez que são usados, não sempre.

Quais são os erros comuns que as pessoas cometem