O documento fornece diversas recomendações para otimizar o desempenho de bancos de dados PostgreSQL em ambientes de alta concorrência, incluindo limitar o número de conexões simultâneas, modelar corretamente os dados, ajustar configurações do SO, PostgreSQL e realizar testes de carga.

1. Fazendo uma manada de elefantes passar debaixo da porta

3. OLTP ;

4. Crescimentos de GBs ao dia;

5. LOCKs inferno ;

7. OLTP ;

8. Crescimentos de GBs ao dia;

9. LOCKs inferno ;

11. Hot Blocks (muitas pessoas querendo acesso ao mesmo bloco de dados);

12. Locks , Dead Locks , problemas de serialização de transações;

13. Gargalos em processador, memória, disco e rede, tudo ao mesmo tempo .

15. Jamais abrir mais de uma conexão por client ;

16. Não usar muitas conexões em client/server . Utilize uma camada intermediária;

17. pgmemcache ;

18. ALTER ROLE role_name SET statement_timeout = xxx;

19. Morte às conexões em <IDLE>

20. Genocídio para <IDLE> In transaction ;

22. Faça testes que emulem a carga real da aplicação como um todo;

23. Faça o rollout da aplicação aumentando o número de conexões gradativamente ;

24. Coloque pontos de medição em vários pontos da aplicação;

25. Crie medições de referência ;

26. Monitore a aplicação, a rede e o SGDB;

27. Entenda a diferença entre saber e achar .

29. Leva horas para mostrar a catástrofe em alta concorrência;

31. Use hstore e vetores para dados pouco estruturados;

32. Acerte os tipos de dados ;

33. Valide os dados antes de gravar e limpe o que não é necessário;

34. Abomine os gatilhos

35. Não implemente pilhas e filas no banco de dados;

36. Chaves compostas facilitam o particionamento de tabelas;

38. Memória importa: quanto de memória você vai disponibilizar por conexão ?

39. Disco importa, como sempre, particularmente para o pg_xlog: quantos COMMITs por segundo você pretende suportar?

40. Cache de gravação realmente importa ;

42. semáforos

43. file-max

45. nofile

47. Ajuste cuidadosamente o autovacuum ;

50. Rotacione o seu log, ele poderá crescer muito rapidamente:

51. max_connections : faça o impossível e inimaginável para manter este número abaixo de 500.

53. Limite ao máximo quais bases e quais usuários vão se conectar;

54. Rejeite usuários/grupos e redes desconhecidas;

56. Diminua o fillfactor em tabelas que poderão crescer com UPDATEs;

57. Rode o ANALYZE ao término de cada processo de carga;

58. Agende o ANALYZE para tabelas onde você desligou o autovacuum em horários estratégicos;

59. Rode o VACUUM nas tabelas onde você desligou o autovacuum para uma janela de manutenção;

60. Aumente o cache de sequências muito utilizadas .

62. Exporte e importe com COPY ;

63. Se uma consulta retorna mais de 100 linhas , então isto deveria ser considerada uma exportação;

64. Não utilize PREPARE e EXECUTE sem critério um bom motivo para isso.

65. Nunca, jamais, em hipótese alguma, execute várias consultas idênticas , com apenas alguns parâmetros variando. Use subconsultas;

67. Modele sua arquitetura pensando em alta concorrência, nem que você tenha que jogar uma boa parte do que já tem no lixo;