Início / dba / Perguntas / 322000
Accepted
J.Hudler
Asked: 2023-01-12 10:58:24 +0800 CST

Postgresql - lista de seleção/projeção de coluna longa leva a desempenho ruim

  • 772

Eu tenho uma consulta estruturalmente "simples" que consiste basicamente nessas cláusulas:

SELECT
  [650 columns here]
FROM
   MAIN_TABLE
   (Several Joins)
WHERE
   (Some conditions in MAIN_TABLE plus some others)

Como alguém pode dizer, a projeção da coluna é bastante grande. Quando digo que a consulta é "simples", quero dizer que ela possui poucas (3) subconsultas na SELECTcláusula que são bastante diretas. Fora isso, não possui CTE's, sub-seleções em cláusulas Join, agrupamento, classificação e assim por diante.

Esta consulta está oscilando entre 20 e 25 segundos para ser concluída.

Agora, se eu começar a extrair aleatoriamente algumas dessas colunas, em algum momento, o desempenho da consulta melhora repentina e significativamente (de 20s para 1-2s).

Se eu exportar o banco de dados (que é pequeno agora, nova implantação, tamanho total de aproximadamente 1 Gb) e executar a mesma consulta na minha máquina de desenvolvimento, ela será executada ainda mais rápido: 0,5s

Suponho que, até certo ponto, o mecanismo deve usar algum buffer de disco como armazenamento intermediário antes de buscar os resultados. O que me incomoda é que essa modificação de seleção de coluna altera tanto o desempenho interno do plano de consulta (ou seja, as tabelas de início da consulta em si) sem motivo aparente.

Como posso diagnosticar corretamente o que está acontecendo e resolver esse problema - algum conselho?

Mais informações

  • PostgreSQL Versão 14.5
  • SO: Rocky Linux 9.0 (Blue Onyx)
  • Os parâmetros são seguidos com base na sugestão do pgTune - o servidor tem muito mais CPU/RAM do que o necessário até agora
  • Já configurei o parâmetro WORK_MEM para um valor grande (100x o original) para uma sessão, mesmo resultado.

Plano de consulta lenta

Plano de consulta rápida (limite de 10.000 linhas adicionado)

Plano de consulta rápida (algumas colunas foram removidas)

postgresql

1 respostas

  1. Best Answer

    Acontece que quase todo o tempo de processamento neste caso está relacionado ao JIT da consulta.

    postgres.confDefinir o sinalizador de sessão ou de todo o sistema jit=offresolveu o problema.

    Agradecimento especial a @jjanes que orientou para o uso de um profiler (que eu estava cético, confesso).

    As perf report3 primeiras linhas foram:

    Overhead  Command     Shared Object         Symbol
  39.31%  postmaster  libLLVM-13.so         [.] llvm::SUnit::addPred
   7.80%  postmaster  libLLVM-13.so         [.] llvm::ScheduleDAGInstrs::addChainDependencies
   6.90%  postmaster  libLLVM-13.so         [.] llvm::MachineInstr::mayAlias
    • 1

relate perguntas