[firebase-br] Índice e operador de menor/maior

[Daniel / Tecnobyte]

Estou fazendo alguns testes por aqui e cheguei a uma situação curiosa. Criei
uma tabela com a estrutura abaixo:

CREATE TABLE Trunca(
  Codigo  INTEGER NOT NULL,
  Valor1  NUMERIC(18,4) NOT NULL,
  Valor2  NUMERIC(18,4) NOT NULL,
  Seguro  NUMERIC(18,4) NOT NULL,
  UDF1    NUMERIC(18,4) COMPUTED(TBTruncDec(Valor1 * Valor2, 4)),
  UDF2    COMPUTED(TBTruncDec(Valor1 * Valor2, 4)),
  Erro    SMALLINT NOT NULL,
  CONSTRAINT PK_Trunca PRIMARY KEY(Codigo));

CREATE INDEX IDX_Trunca_Erro ON Trunca(Erro);

Via programa feito em Delphi, inseri alguns milhões de registros nesta
tabela (6.198.200). Rodei o SELECT abaixo com vários filtros diferentes e
notei todas as vezes em que os operadores < e > foram usados com o campo
"Erro" o tempo de resposta foi demasiadamente longo, mesmo usando índice.

SELECT * FROM Trunca

---------- Filtrando pelo campo Erro, o qual tem índice
secundário -----------

Filtro: Erro > 0
Linhas retornadas: nenhuma
Tempo: mais de 2 minutos
PLAN (TRUNCA INDEX (IDX_TRUNCA_ERRO))

Filtro: Erro < 0
Linhas retornadas: nenhuma
Tempo: quase 2 minutos
PLAN (TRUNCA INDEX (IDX_TRUNCA_ERRO))

Filtro: Erro = 1
Linhas retornadas: nenhuma
Tempo: instantâneo
PLAN (TRUNCA INDEX (IDX_TRUNCA_ERRO))

---------- Filtrando pelo campo Codigo, que é chave-primária ----------

Filtro: Codigo > 7000000
Linhas retornadas: nenhuma
Tempo: instantâneo
PLAN (TRUNCA INDEX (PK_TRUNCA))

Filtro: Codigo < 0
Linhas retornadas: nenhuma
Tempo: instantâneo
PLAN (TRUNCA INDEX (PK_TRUNCA))

Filtro: Codigo = 100
Linhas retornadas: uma
Tempo: instantâneo
PLAN (TRUNCA INDEX (PK_TRUNCA))

Dúvida:

Porque os operadores relacionais < e > são tão lentos quando está sendo
usado um índice secundário? Seria um problema no otimizador do Firebird?
Alguém sabe alguma coisa sobre isto?

Atenciosamente.

Daniel P. Guimarães
Tecnobyte informática