Desvendando os Locks no PostgreSQL: LWLocks e LockManager
Iago Passos
Timbira
Entender de vez como o Postgres lida com concorrência. Vamos desvendar LWLocks, gargalos ocultos e otimizar o banco em cenários de alta carga.
Você já passou pela situação em que a aplicação começa a sofrer, a latência dispara e a primeira coisa que vem à mente é: "temos problemas de lock no banco"? Nós aprendemos na teoria que bloqueios são essenciais para garantir a integridade dos nossos dados, mas, no mundo real, quando lidamos com alto voume de dados, eles costumam ser os vilões da escalabilidade.
Nesta palestra, eu quero passar por cima do Postgres. A ideia é sair da superfície e entender como o banco realmente se comporta quando o assunto é concorrência. Vamos conversar sobre o que a documentação oficial muitas vezes não te conta de forma tão clara e direta.
Vai começar com: qual é a diferença real, na prática, entre os famosos Lightweight Locks (LWLocks) e os Heavyweight Locks? Como o Postgres adquire e gerencia bloqueios no nível das tabelas e índices? Mais importante do que isso: vou mostrar cenários práticos e muitas vezes contraintuitivos, como o fato de que ter muitos índices em uma tabela pode gerar lentidão até mesmo em queries que só fazem leitura, por conta da temida contenção no LockManager.
Avançando um pouco mais, vamos olhar para as soluções que o próprio PostgreSQL tem para nos ajudar. Vamos entender como funciona o fast-path locking e descobrir os mistérios por trás de configurações que quase todo mundo tem medo de mexer, como o max_locks_per_transaction. Por que ele importa tanto? Quando você deve se preocupar em ajustá-lo?
Por fim, vamos tocar em um ponto crítico do nosso dia a dia: a observabilidade. Todo mundo quer monitorar o que está travando o banco, certo? Mas você sabia que ficar rodando scripts de monitoramento o tempo todo (como consultas abusivas à função pg_blocking_pids()) pode causar um "efeito observador" e derrubar de vez a performance do seu banco? Vou te mostrar como monitorar do jeito certo, identificando o problema sem atirar no próprio pé.
Ao sair dessa sessão, meu objetivo é que não veja mais os locks como um bicho de sete cabeças. Terá um modelo mental muito mais claro sobre a arquitetura do banco, ganhando autonomia para diagnosticar gargalos reais em produção e desenhar sistemas muito mais eficientes para aplicações que precisam escalar de verdade.
Desvendando os Locks no PostgreSQL: LWLocks e LockManager
Iago Passos
Timbira
Entender de vez como o Postgres lida com concorrência. Vamos desvendar LWLocks, gargalos ocultos e otimizar o banco em cenários de alta carga.
Você já passou pela situação em que a aplicação começa a sofrer, a latência dispara e a primeira coisa que vem à mente é: "temos problemas de lock no banco"? Nós aprendemos na teoria que bloqueios são essenciais para garantir a integridade dos nossos dados, mas, no mundo real, quando lidamos com alto voume de dados, eles costumam ser os vilões da escalabilidade.
Nesta palestra, eu quero passar por cima do Postgres. A ideia é sair da superfície e entender como o banco realmente se comporta quando o assunto é concorrência. Vamos conversar sobre o que a documentação oficial muitas vezes não te conta de forma tão clara e direta.
Vai começar com: qual é a diferença real, na prática, entre os famosos Lightweight Locks (LWLocks) e os Heavyweight Locks? Como o Postgres adquire e gerencia bloqueios no nível das tabelas e índices? Mais importante do que isso: vou mostrar cenários práticos e muitas vezes contraintuitivos, como o fato de que ter muitos índices em uma tabela pode gerar lentidão até mesmo em queries que só fazem leitura, por conta da temida contenção no LockManager.
Avançando um pouco mais, vamos olhar para as soluções que o próprio PostgreSQL tem para nos ajudar. Vamos entender como funciona o fast-path locking e descobrir os mistérios por trás de configurações que quase todo mundo tem medo de mexer, como o max_locks_per_transaction. Por que ele importa tanto? Quando você deve se preocupar em ajustá-lo?
Por fim, vamos tocar em um ponto crítico do nosso dia a dia: a observabilidade. Todo mundo quer monitorar o que está travando o banco, certo? Mas você sabia que ficar rodando scripts de monitoramento o tempo todo (como consultas abusivas à função pg_blocking_pids()) pode causar um "efeito observador" e derrubar de vez a performance do seu banco? Vou te mostrar como monitorar do jeito certo, identificando o problema sem atirar no próprio pé.
Ao sair dessa sessão, meu objetivo é que não veja mais os locks como um bicho de sete cabeças. Terá um modelo mental muito mais claro sobre a arquitetura do banco, ganhando autonomia para diagnosticar gargalos reais em produção e desenhar sistemas muito mais eficientes para aplicações que precisam escalar de verdade.