SEQUENTIAL SCANS



Version IDS 10

I am running a query something like this:

table A (column s, column t, column u, column v)
table A has individual index on column s.
table A has another individual index on column t.
table A has another individual index on column u.
Update stats have run as high on these columns

table B (column w, column x)
table B has individual index on column w.
table B has another individual index on column x.
Update stats have run as high on these columns

select * from A, B where A.s = 1200 and B.w = A.t;

Above query correctly takes INDEX PATH.

Now I change the query to:

select * from A, B where A.s = 1200 and (B.w = A.t or B.w = A.u);

set explain shows that it did SEQUENTIAL SCAN on table B.

It's perplexing why would optimizer behave like this. It should be
taking index path for the second query too.
.



Relevant Pages

  • Re: SEQUENTIAL SCANS
    ... table A has another individual index on column t. ... Above query correctly takes INDEX PATH. ... you did run update statistics low for table B, ...
    (comp.databases.informix)
  • Re: SEQUENTIAL SCANS
    ... table A has another individual index on column t. ... Above query correctly takes INDEX PATH. ... It's perplexing why would optimizer behave like this. ...
    (comp.databases.informix)
  • Re: SEQUENTIAL SCANS
    ... table A has another individual index on column t. ... Update stats have run as high on these columns ... Above query correctly takes INDEX PATH. ...
    (comp.databases.informix)
  • Re: SEQUENTIAL SCANS
    ... table A has another individual index on column t. ... Update stats have run as high on these columns ... Above query correctly takes INDEX PATH. ...
    (comp.databases.informix)
  • Re: SEQUENTIAL SCANS
    ... table A has another individual index on column t. ... Above query correctly takes INDEX PATH. ... It's perplexing why would optimizer behave like this. ... Indexread B, Indexread A - do a nested loop join ...
    (comp.databases.informix)