Por que o PostgreSQL está escolhendo o pedido de adesão mais caro?

PostgreSQL usando padrões, além de

default_statistics_target=1000
random_page_cost=1.5

Versão

PostgreSQL 10.4 on x86_64-pc-linux-musl, compiled by gcc (Alpine 6.4.0) 6.4.0, 64-bit

Eu aspirei e analisei. A consulta é muito direta:

SELECT r.price
FROM account_payer ap
  JOIN account_contract ac ON ap.id = ac.account_payer_id
  JOIN account_schedule "as" ON ac.id = "as".account_contract_id
  JOIN schedule s ON "as".id = s.account_schedule_id
  JOIN rate r ON s.id = r.schedule_id
WHERE ap.account_id = 8

Cada idcoluna é a chave primária, e tudo o que está sendo associado é um relacionamento de chave estrangeira e cada chave estrangeira tem um índice. Além de um índice para account_payer.account_id.

São necessários 3,93s para retornar 76k linhas.

Merge Join  (cost=8.06..83114.08 rows=3458267 width=6) (actual time=0.228..3920.472 rows=75548 loops=1)
  Merge Cond: (s.account_schedule_id = "as".id)
  ->  Nested Loop  (cost=0.57..280520.54 rows=6602146 width=14) (actual time=0.163..3756.082 rows=448173 loops=1)
        ->  Index Scan using schedule_account_schedule_id_idx on schedule s  (cost=0.14..10.67 rows=441 width=16) (actual time=0.035..0.211 rows=89 loops=1)
        ->  Index Scan using rate_schedule_id_code_modifier_facility_idx on rate r  (cost=0.43..486.03 rows=15005 width=10) (actual time=0.025..39.903 rows=5036 loops=89)
              Index Cond: (schedule_id = s.id)
  ->  Materialize  (cost=0.43..49.46 rows=55 width=8) (actual time=0.060..12.984 rows=74697 loops=1)
        ->  Nested Loop  (cost=0.43..49.32 rows=55 width=8) (actual time=0.048..1.110 rows=66 loops=1)
              ->  Nested Loop  (cost=0.29..27.46 rows=105 width=16) (actual time=0.030..0.616 rows=105 loops=1)
                    ->  Index Scan using account_schedule_pkey on account_schedule "as"  (cost=0.14..6.22 rows=105 width=16) (actual time=0.014..0.098 rows=105 loops=1)
                    ->  Index Scan using account_contract_pkey on account_contract ac  (cost=0.14..0.20 rows=1 width=16) (actual time=0.003..0.003 rows=1 loops=105)
                          Index Cond: (id = "as".account_contract_id)
              ->  Index Scan using account_payer_pkey on account_payer ap  (cost=0.14..0.21 rows=1 width=8) (actual time=0.003..0.003 rows=1 loops=105)
                    Index Cond: (id = ac.account_payer_id)
                    Filter: (account_id = 8)
                    Rows Removed by Filter: 0
Planning time: 5.843 ms
Execution time: 3929.317 ms

Se eu definir join_collapse_limit=1, são necessários 0,16s, uma aceleração de 25x.

Nested Loop  (cost=6.32..147323.97 rows=3458267 width=6) (actual time=8.908..151.860 rows=75548 loops=1)
  ->  Nested Loop  (cost=5.89..390.23 rows=231 width=8) (actual time=8.730..11.655 rows=66 loops=1)
        Join Filter: ("as".id = s.account_schedule_id)
        Rows Removed by Join Filter: 29040
        ->  Index Scan using schedule_pkey on schedule s  (cost=0.27..17.65 rows=441 width=16) (actual time=0.014..0.314 rows=441 loops=1)
        ->  Materialize  (cost=5.62..8.88 rows=55 width=8) (actual time=0.001..0.011 rows=66 loops=441)
              ->  Hash Join  (cost=5.62..8.61 rows=55 width=8) (actual time=0.240..0.309 rows=66 loops=1)
                    Hash Cond: ("as".account_contract_id = ac.id)
                    ->  Seq Scan on account_schedule "as"  (cost=0.00..2.05 rows=105 width=16) (actual time=0.010..0.028 rows=105 loops=1)
                    ->  Hash  (cost=5.02..5.02 rows=48 width=8) (actual time=0.178..0.178 rows=61 loops=1)
                          Buckets: 1024  Batches: 1  Memory Usage: 11kB
                          ->  Hash Join  (cost=1.98..5.02 rows=48 width=8) (actual time=0.082..0.143 rows=61 loops=1)
                                Hash Cond: (ac.account_payer_id = ap.id)
                                ->  Seq Scan on account_contract ac  (cost=0.00..1.91 rows=91 width=16) (actual time=0.007..0.023 rows=91 loops=1)
                                ->  Hash  (cost=1.64..1.64 rows=27 width=8) (actual time=0.048..0.048 rows=27 loops=1)
                                      Buckets: 1024  Batches: 1  Memory Usage: 10kB
                                      ->  Seq Scan on account_payer ap  (cost=0.00..1.64 rows=27 width=8) (actual time=0.009..0.023 rows=27 loops=1)
                                            Filter: (account_id = 8)
                                            Rows Removed by Filter: 24
  ->  Index Scan using rate_schedule_id_code_modifier_facility_idx on rate r  (cost=0.43..486.03 rows=15005 width=10) (actual time=0.018..1.685 rows=1145 loops=66)
        Index Cond: (schedule_id = s.id)
Planning time: 4.692 ms
Execution time: 160.585 ms

Essas saídas fazem pouco sentido para mim. O primeiro tem um custo (muito alto) de 280.500 para a junção de loop aninhado para os índices de programação e taxa. Por que o PostgreSQL escolhe intencionalmente essa junção muito cara primeiro?

Informações adicionais solicitadas por comentários

É rate_schedule_id_code_modifier_facility_idxum índice composto?

É, por schedule_idser a primeira coluna. Criei um índice dedicado e ele foi escolhido pelo planejador de consultas, mas não afeta o desempenho nem afeta o plano.

— Paul Draper
fonte

Você pode alterar as configurações default_statistics_targete random_page_costretornar aos seus padrões? O que acontece quando você aumenta default_statistics_targetainda mais? Você pode criar um DB Fiddle (em dbfiddle.uk) e tentar reproduzir o problema lá?

— Colin 'Hart

Você pode inspecionar as estatísticas reais para ver se há algo distorcido / estranho nos seus dados? postgresql.org/docs/10/static/planner-stats.html

— Colin 't Hart

Qual é o valor atual para o parâmetro work_mem? Mudá-lo dá tempos diferentes?

— eppesuig

Parece que suas estatísticas não são precisas (execute a análise de vácuo para atualizá-las) ou você tem colunas correlacionadas em seu modelo (e, portanto, precisará executar create statisticspara informar o planejador desse fato).

O join_collapseparâmetro permite que o planejador reorganize as junções para que ele execute primeiro aquele que busca menos dados. Mas, para o desempenho, não podemos deixar o planejador fazer isso em uma consulta com muitas junções. Por padrão, é definido como 8 junções no máximo. Ao defini-lo como 1, você simplesmente desativa essa capacidade.

Então, como o postgres prevê quantas linhas essa consulta deve buscar? Ele usa estatísticas para estimar o número de linhas.

O que podemos ver nos seus planos de explicação é que existem várias estimativas imprecisas do número de linhas (o primeiro valor é estimado, o segundo é real).

Por exemplo, aqui:

Materialize  (cost=0.43..49.46 rows=55 width=8) (actual time=0.060..12.984 rows=74697 loops=1)

O planejador calculou obter 55 linhas quando recebeu 74697.

O que eu faria (se estivesse no seu lugar) é:

analyze as cinco tabelas envolvidas para atualizar as estatísticas
Repetir explain analyze
Veja a diferença entre os números de linha estimados e os números de linha reais
Se os números das linhas estimadas estiverem corretos, talvez o plano tenha mudado e seja mais eficiente. Se estiver tudo bem, considere alterar as configurações de vácuo automático para analisar (e aspirar) com mais frequência
Se os números de estimativa de linha ainda está errado, parece que você têm correlacionado os dados na sua tabela (terceira forma normal violação) .Você pode considerar declarando-o com CREATE STATISTICS(documentação aqui )

Se você precisar de mais informações sobre estimativas de linha e seus cálculos, encontrará tudo o que precisa na conversa de Tomas Vondra "Criar estatísticas - para que serve?" (slides aqui )

— Arkhena
fonte