Zdravím,
narazil jsem na zajímavou vec v postgresu (7.0): mám tabulku,
zachycující stromovou strukturu:
| ctc002=> \d nodes
| Table "nodes"
| Attribute | Type | Modifier
| -----------+---------+------------------------------------------------
| id | integer | not null default nextval('nodes_id_seq'::text)
| father | integer |
| type | integer |
| alias | text |
| Indices: nodes_alias_key,
| nodes_pkey
(nodes_pkey je unique btree na id)
Zkusím tohle:
| ctc002=> explain select * from nodes where id=12;
| NOTICE: QUERY PLAN:
|
| Index Scan using nodes_pkey on nodes (cost=0.00..8.14 rows=10 width=4)
proč je výsledkem index scanu 10 řádků?
Vzpomenu si, že se typicky vyhledává s podmínkou na fathera, takže
| ctc002=> create index nodes_father on nodes(father);
Zkusím ten samý explain znova:
| ctc002=> explain select * from nodes where id=12;
| NOTICE: QUERY PLAN:
|
| Seq Scan on nodes (cost=0.00..1.48 rows=1 width=4)
Najednou se místo index scanu použije seq scan a očekává se, že
bude mnohem levnější. Čím to, že vytvořením indexu na jiném poli
se změní plán vyhodnocení dotazu? Navíc, tento plán zvítězí,
i když index nodes_father zruším.
Z praktického hlediska je mi to zatím jedno, není tam tolik tolik
dat... Spíše mě vadí, že si toto chování nedokážu vysvětlit :-)
zdraví
martin