Explain/Optimering

PostgreSQL har desværre en kedelig bagside - den styrre ikke rigtig brugen af indexes m.m. Men hvor om alt er, så skal jeg altså bruge postgreSQL og må derfor finde en løsning.

Se på følgende tabeller:

CREATE TABLE \"folder2\" (
        \"id\" int4 NOT NULL,
        \"title\" character varying(255) NOT NULL,
        \"keywords\" character varying(255),
        \"description\" text,
        \"sort_by\" character varying(10) NOT NULL,
        \"folder_type\" character varying(10),
        Constraint \"folder_pkey\" Primary Key (\"id\")
);

CREATE TABLE \"objects2\" (
        \"num_id\" int4 DEFAULT nextval(\'objects_num_id_seq\') NOT NULL,
        \"id\" int4 NOT NULL,
        \"parent\" character varying(40) NOT NULL,
        \"site_id\" character varying(40) NOT NULL,
        \"type\" character varying(20) NOT NULL, 
        \"sort_order\" int4 NOT NULL,
        \"date_updated\" timestamp with time zone NOT NULL,
        \"user_id\" character varying(40) NOT NULL,
        \"status\" int2 DEFAULT 1 NOT NULL,
        Constraint \"objects_pkey\" Primary Key (\"id\")
);
create index objects_status_index on objects2(status);


Og se så hvad der sker...

explain
select t1.id, t1.sort_by
from folder t1, objects t2
where t1.id = t2.id
and status = int2(1) or status = int2(0)
and sort_by <> \'manual\'
;

Nested Loop  (cost=0.00..55276.84 rows=23425 width=38)
  ->  Index Scan using objects_status_index, objects_status_index on objects t2  (cost=0.00..1241.48 rows=1201 width=14)
  ->  Seq Scan on folder t1  (cost=0.00..20.00 rows=1000 width=24)

Den laver en Seq scan på folder2 tabellen selv om der er index på id! Det sjove er så, at fjerner jeg status sammenligningen, så benytter den index\'et på folder2 tabellen - total trist at det er sådan.

Bemærk iøvrigt hvordan det er nødvendigt at typecaste for at få den til at benytte index på status kolonnen...