índice composto em (A,B) + índice único em (A): o postgres está usando single quando "deveria" usar composto?

Existem vários posts bons, por exemplo:

Devo usar um índice composto ou de coluna única?

mostrando que se você tiver um índice composto nas colunas (A,B) e um índice único em (A), o postgres usará o índice composto (para melhorar o cache), e o índice único é supérfluo e pode ser descartado.

Ao testar isso, percebo que o postgres às vezes usará o índice único quando o composto estiver disponível, mas não sei se isso significa que ainda precisamos (para desempenho da consulta) de ambos os índices.

Considere o seguinte:

CREATE TABLE public.events (
    id serial4 NOT NULL,
    reference int4 NOT NULL,
    "name" varchar(255) NULL,
    bet_source varchar NULL,
    CONSTRAINT events_pkey PRIMARY KEY (id),
    CONSTRAINT events_reference_betsource_key UNIQUE (reference, bet_source)
);
CREATE INDEX event_reference ON public.events USING btree (reference);

Aqui, a pequena diferença é que o índice composto é único e foi declarado como uma restrição (que presumo ser o mesmo que criar um índice único).

explain (analyze, buffers)
select * from events e where e.reference = 123;

Index Scan using event_reference on events e  (cost=0.28..8.30 rows=1 width=51) (actual time=0.006..0.007 rows=0 loops=1)
  Index Cond: (reference = 123)
  Buffers: shared hit=2
Planning:
  Buffers: shared hit=69 dirtied=1
Planning Time: 0.432 ms
Execution Time: 0.036 ms

Aqui podemos ver no plano de explicação que o postgres optou por usar o índice único. Normalmente, quando testei isso em outras tabelas, o postgres escolhe o índice composto neste caso.

A questão é,

1. estou seguro para remover event_reference sem afetar o desempenho da consulta? Como não tenho acesso aos dados de produção (ou a uma cópia deles), seria difícil testar isso com dados reais.

2. é uma restrição exclusiva igual a um índice exclusivo (para fins de consulta e otimização de inserção)