Índice não sendo usado na consulta SELECT

Eu tenho uma tabela de cerca de 3,25 milhões de linhas com o seguinte formato no Postgres 9.4.1

CREATE TABLE stats
(
    id serial NOT NULL,
    type character varying(255) NOT NULL,
    "references" jsonb NOT NULL,
    path jsonb,
    data jsonb,
    "createdAt" timestamp with time zone NOT NULL,
    CONSTRAINT stats_pkey PRIMARY KEY (id)
)
WITH (
    OIDS=FALSE
);

O typeé uma string simples com no máximo 50 caracteres.

A referencescoluna é um objeto com uma lista de valores-chave. Basicamente, qualquer lista de valores de chave simples e apenas 1 nível de profundidade, os valores são sempre strings. Poderia ser

{
    "fruit": "plum"
    "car": "toyota"
}

ou pode ser

{
    "project": "2532"
}

O createdAttimestamp nem sempre é gerado a partir do banco de dados (mas será por padrão se um valor não for fornecido)

No momento, estou usando a tabela apenas com dados de teste. Nesses dados, cada linha tem uma projectchave como referência. Portanto, há 3,25 milhões de linhas com uma chave de projeto. Existem exatamente 400.000 valores distintos para a projectreferência. Existem apenas 5 valores distintos para o typecampo, isso provavelmente não passaria de algumas centenas em produção.

Então estou tentando indexar a tabela para realizar a seguinte query rapidamente:

SELECT
  EXTRACT(EPOCH FROM (MAX("createdAt") - MIN("createdAt"))) 
FROM
  stats
WHERE
  stats."references"::jsonb ? 'project' AND
  (
    stats."type" = 'event1' OR
    (
      stats."type" = 'event2' AND
      stats."createdAt" > '2015-11-02T00:00:00+08:00' AND
      stats."createdAt" < '2015-12-03T23:59:59+08:00'
    )
  )
GROUP BY stats."references"::jsonb->> 'project'

A consulta retorna a distância de tempo entre dois eventos com base em duas linhas de estatísticas que têm a mesma referência. Neste caso project. Sempre há apenas 1 linha para cada valor typeselecionado reference, mas também pode não haver linhas, caso em que o resultado retornado é 0 (isso é calculado posteriormente em uma parte diferente de uma consulta maior).

Eu criei um índice nas colunas createdAt typee references, mas o plano de execução da consulta parece estar fazendo uma verificação completa.

O índice

CREATE INDEX "stats_createdAt_references_type_idx"
    ON stats
    USING btree
    ("createdAt", "references", type COLLATE pg_catalog."default");

Plano de execução:

 HashAggregate  (cost=111188.31..111188.33 rows=1 width=38) 
                (actual time=714.499..714.499 rows=0 loops=1)
   Group Key: ("references" ->> 'project'::text)
      ->  Seq Scan on stats  (cost=0.00..111188.30 rows=1 width=38) 
                             (actual time=714.498..714.498 rows=0 loops=1)
          Filter: (
              (("references" ? 'project'::text) 
               AND ((type)::text = 'event1'::text)) OR 
              (((type)::text = 'event2'::text) 
               AND ("createdAt" > '2015-11-02 05:00:00+13'::timestamp with time zone) 
               AND ("createdAt" < '2015-12-04 04:59:59+13'::timestamp with time zone)))

Rows Removed by Filter: 3258680
Planning time: 0.163 ms
Execution time: 714.534 ms

Eu realmente não estou tão informado sobre planos de execução de indexação e consulta, então se alguém pudesse me indicar a direção certa, seria ótimo.

Editar

Conforme observado por Erwin, parece que mesmo se eu tivesse os índices corretos, uma verificação da tabela ainda ocorreria, pois a parte da tabela retornada da consulta é muito grande. Isso significa que, para esse conjunto de dados, esse é o tempo de consulta mais rápido que posso obter? Estou assumindo que se eu adicionasse mais 60 milhões de linhas não relacionadas sem uma referência de projeto, ele poderia usar um índice (se eu tivesse os índices corretos), mas não vejo como isso poderia acelerar a consulta adicionando mais dados. Talvez eu esteja perdendo alguma coisa.