it dont seems to work, but in my context I only needed data from the
rt_node table so I tried this:
from rt_node n
where node_id = 2
and exists (select edge_id from rt_edge where start_node_id =
n.node_id or end_node_id = n.node_id)
and it gave me this plan (even if I remove the stupid node_id = 2 condition):
Index Scan using rt_node_pkey on rt_node n (cost=0.00..6.15 rows=1 width=25)
Index Cond: (node_id = 2)
-> Index Scan using rt_edge_start_node, rt_edge_end_node on
rt_edge (cost=0.00..12.56 rows=4 width=4)
Index Cond: ((start_node_id = $0) OR (end_node_id = $0))
this time it use my two indexes, maybe because he know that the same
value is compared in the two condition... I should ask my mother if
she got an idea, mothers know a lot of stuff!
On 5/25/05, John A Meinel <[EMAIL PROTECTED]> wrote:
> Jocelyn Turcotte wrote:
> >Hi all
> >i dont know if this is normal, but if yes i would like to know why and
> >how I could do it another way other than using unions.
> The only thing that *might* work is if you used an index on both keys.
> So if you did:
> CREATE INDEX rt_edge_start_end_node ON rt_edge(start_node_id,end_node_id);
> The reason is that in an "OR" construct, you have to check both for being
> true. So in the general case where you don't know the correlation between the
> columns, you have to check all of the entries, because even if you know the
> status of one side of the OR, you don't know the other.
> Another possibility would be to try this index:
> CREATE INDEX rt_edge_stare_or_end ON rt_edge(start_node_id OR end_node_id);
> I'm not sure how smart the planner can be, though.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly