Como @Chris comentou corretamente na questão referenciada :

uma pequena investigação parece indicar que a condição de nova verificação é sempre impressa no EXPLAIN, mas na verdade só é executada quando work_memé pequena o suficiente para que o bitmap fique com perdas. Pensamentos? http://www.postgresql.org/message-id/[email protected]

Embora tudo isso seja verdade e o desenvolvedor central Heikki Linnakangas seja uma fonte de primeira classe, o post data de 2007 (Postgres 8.2). Aqui está uma postagem no blog de Michael Paquier com uma explicação detalhada do Postgres 9.4 , onde a saída EXPLAIN ANALYZEfoi aprimorada com mais informações.

A Recheck Cond:linha está sempre presente para varreduras de índice de bitmap. A saída de basic EXPLAINnão nos dirá mais. Obtemos informações adicionais de EXPLAIN ANALYZEcomo pode ser visto na segunda citação na pergunta:

Heap Blocks: exact=693 lossy=3732

De um total de 4.425 páginas de dados (blocos), 693 tuplas foram armazenadas exatamente (incluindo ponteiros de tupla), enquanto as outras 3.732 páginas tiveram perdas (apenas a página de dados) no bitmap. Isso acontece quando work_memnão é grande o suficiente para armazenar todo o bitmap construído a partir da varredura de índice exatamente (sem perdas).

A condição do índice deve ser verificada novamente para páginas do compartilhamento com perdas, pois o bitmap lembra apenas quais páginas buscar e não as tuplas exatas na página. Nem todas as tuplas na página passarão necessariamente pelas condições do índice, é necessário verificar novamente a condição.

Este é o tópico sobre hackers pgsql onde a nova adição foi discutida . O autor Etsuro Fujita fornece uma fórmula de como calcular o mínimo work_mempara evitar entradas de bitmap com perdas e verificações de condição subsequentes. O cálculo não é confiável para casos complexos com várias varreduras de bitmap, portanto, não foi usado para gerar números reais de EXPLAIN. Ainda pode servir como estimativa para casos simples.

Linha adicionalBUFFERS:

Além disso, ao executar com a BUFFERSopção: EXPLAIN (ANALYZE, BUFFERS) ...outra linha é adicionada como:

Buffers: shared hit=279 read=79

Isso indica quanto da tabela subjacente (e índice) foi lido do cache ( shared hit=279) e quanto teve que ser obtido do disco ( read=79). Se você repetir a consulta, a parte "lida" normalmente desaparece para consultas não muito grandes, porque tudo é armazenado em cache agora após a primeira chamada. A primeira chamada informa quanto já foi armazenado em cache. As chamadas subseqüentes mostram quanto seu cache pode suportar (atualmente).

Existem mais opções. O manual sobre a BUFFERSopção:

Especificamente, inclua o número de blocos compartilhados atingidos, lidos, sujos e gravados, o número de blocos locais atingidos, lidos, sujos e gravados e o número de blocos temporários lidos e gravados.

Leia, há mais.
Aqui está a lista de opções de saída no código-fonte .

Erwin, já que essa foi a nossa discussão no tópico de comentários anterior, decidi cutucar um pouco mais...

Eu tenho uma consulta muito simples de uma tabela de tamanho razoável. Eu normalmente tenho o suficiente work_mem, mas neste caso usei os comandos

SET work_mem = 64;

para definir um muito pequeno work_meme

SET work_mem = default;

para definir minhas work_memcostas para ser suficientemente grande para minha consulta.

EXPLICAR e verificar novamente a condição

Então, executando minha consulta com EXPLAINapenas

EXPLAIN 
SELECT * FROM olap.reading_facts
WHERE meter < 20;

Eu obtive os resultados para baixo e alto work_mem:

Baixowork_mem

Bitmap Heap Scan on reading_facts  (cost=898.92..85632.60 rows=47804 width=32)
  Recheck Cond: (meter < 20)
  ->  Bitmap Index Scan on idx_meter_reading_facts  (cost=0.00..886.96 rows=47804 width=0)
        Index Cond: (meter < 20)

Altowork_mem

Bitmap Heap Scan on reading_facts  (cost=898.92..85632.60 rows=47804 width=32)
  Recheck Cond: (meter < 20)
  ->  Bitmap Index Scan on idx_meter_reading_facts  (cost=0.00..886.96 rows=47804 width=0)
        Index Cond: (meter < 20)

Para encurtar a história, EXPLAINapenas, como esperado, o plano de consulta indica que uma condição Recheck é possível, mas não podemos saber se será realmente computada.

EXPLICAR ANALISAR E VERIFICAR novamente a condição

Quando incluímos ANALYZEna consulta, os resultados nos dizem mais sobre o que precisamos saber.

Baixowork_mem

Bitmap Heap Scan on reading_facts  (cost=898.92..85632.60 rows=47804 width=32) (actual time=3.130..13.946 rows=51840 loops=1)
  Recheck Cond: (meter < 20)
  Rows Removed by Index Recheck: 86727
  Heap Blocks: exact=598 lossy=836
  ->  Bitmap Index Scan on idx_meter_reading_facts  (cost=0.00..886.96 rows=47804 width=0) (actual time=3.066..3.066 rows=51840 loops=1)
        Index Cond: (meter < 20)

Altowork_mem

Bitmap Heap Scan on reading_facts  (cost=898.92..85632.60 rows=47804 width=32) (actual time=2.647..7.247 rows=51840 loops=1)
  Recheck Cond: (meter < 20)
  Heap Blocks: exact=1434
  ->  Bitmap Index Scan on idx_meter_reading_facts  (cost=0.00..886.96 rows=47804 width=0) (actual time=2.496..2.496 rows=51840 loops=1)
        Index Cond: (meter < 20)

Novamente, como esperado, a inclusão de ANALYZEnos revela algumas informações muito importantes. No work_memcaso baixo, vemos que há linhas removidas pela nova verificação do índice e que temos lossyblocos de heap.

Conclusão? (ou falta dela)

Infelizmente, parece que EXPLAINpor si só não é suficiente para saber se uma nova verificação de índice será realmente necessária porque alguns dos IDs de linha estão sendo descartados em favor da retenção de páginas durante a varredura de heap de bitmap.

Usar EXPLAIN ANALYZEé bom para diagnosticar os problemas com consultas de comprimento moderado, mas no caso de uma consulta levar muito tempo para ser concluída, executar EXPLAIN ANALYZEpara descobrir que seu índice de bitmap está convertendo em com perdas devido a insuficiente work_memainda é uma restrição difícil. Eu gostaria que houvesse uma maneira de EXPLAINestimar a probabilidade dessa ocorrência a partir das estatísticas da tabela.