Re: Inner join on two OR conditions dont use index

Thanks John

it dont seems to work, but in my context I only needed data from the
rt_node table so I tried this:

select *
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)
Filter: (subplan)
SubPlan
-> 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 <john(at)arbash-meinel(dot)com> 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.
>
> John
> =:->
>
>
>
>
>