Zdefiniowałem następującą tabelę i indeksy:

CREATE TABLE ticket
(
  wid bigint NOT NULL DEFAULT nextval('tickets_id_seq'::regclass),
  eid bigint,
  created timestamp with time zone NOT NULL DEFAULT now(),
  status integer NOT NULL DEFAULT 0,
  argsxml text,
  moduleid character varying(255),
  source_id bigint,
  file_type_id bigint,
  file_name character varying(255),
  status_reason character varying(255),
  ...
)

Stworzyłem indeks na stroniecreated znacznik czasu w następujący sposób:

CREATE INDEX ticket_1_idx
  ON ticket
  USING btree
  (created );

i oto moje zapytanie

select * from ticket 
where created between '2012-12-19 00:00:00' and  '2012-12-20 00:00:00'

Działało to dobrze, dopóki liczba rekordów nie zaczęła rosnąć (około 5 milionów), a teraz powrót na zawsze trwa.

Wyjaśnij analizę ujawnia to:

"Index Scan using ticket_1_idx on ticket  (cost=0.00..10202.64 rows=52543 width=1297) (actual time=0.109..125.704 rows=53340 loops=1)"
"  Index Cond: ((created >= '2012-12-19 00:00:00+00'::timestamp with time zone) AND (created <= '2012-12-20 00:00:00+00'::timestamp with time zone))"
"Total runtime: 175.853 ms"

Do tej pory próbowałem ustawienia

random_page_cost = 1.75 
effective_cache_size = 3 

Stworzono również

create CLUSTER ticket USING ticket_1_idx;

Nic nie działa. Co ja robię źle? Dlaczego wybiera skanowanie sekwencyjne? Indeksy mają sprawić, że zapytanie będzie szybkie. Wszystko, co można zrobić, aby to zoptymalizować?