× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



1) Keep in mind that you're doing *NE lookups on the last two fields,
not *EQ. Indexes are much less useful on *NE lookups since you're close
to reading all the records anyway.

2) Could the index it did build have included record selection in the
index? I don't know if the optimizer shows that data in its message. 

-Walden


------------
Walden H Leverich III
President & CEO
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com 

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
 
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rick.baird@xxxxxxxxxxxxxxx
Sent: Tuesday, March 30, 2004 11:51 AM
To: midrange-l@xxxxxxxxxxxx
Subject: query optimizer revisited - this shouldn't be this hard!

Ok, now i'm really starting to get frustrated.

I have an opnqryf statement that I want to run quicker.

OPNQRYF FILE((HISTRY4))
QRYSLT('HPEROD *EQ "06" *AND LMRKTC *NE "00" *AND HITEM *NE 0')
KEYFLD((HITEM) (LMRKTC))

the query optimizer said:  build this index:

HPEROD, LMRKTC, HITEM  (the order is wrong, but I'll take it's word for
it)

i create an index:

CREATE INDEX HISTRY4LA
    ON HISTRY4 (HPEROD, LMRKTC, HITEM)

and re-run the query.  It tells me it considered my index, but rejected
it
because of reason 5:
   5 - The keys of the access path did not match the fields specified
for
the
 ordering/grouping criteria.

ok, reasonable enough.  so I change the opnqryf and the index to match
each
other better, while having the same results.

CREATE INDEX HISTRY4LA
    ON HISTRY4 (HPEROD, HITEM, LMRKTC)

and

OPNQRYF FILE((HISTRY4))
QRYSLT('HPEROD *EQ "06" *AND HITEM *NE 0 *AND LMRKTC *NE "00"')
KEYFLD((HPEROD) (HITEM) (LMRKTC))

I ran again, and it says it considered my index, but rejected it because
of
reason 4.
  4 - The cost to use this access path, as determined by the optimizer,
was
higher than the cost associated with the chosen access method.

So I checked to see what access path WAS built, and this is what it told
me.

HPEROD     ASCEND,  HITEM      ASCEND,  LMRKTC     ASCEND.

BUT THAT'S MY ACCESS PATH!!!  why did it build another access path
exactly
like mine?

This shouldn't be rocket science, but it's obviously harder than it
looks.
I'm about to just start building single purpose logicals and be done
with
it.

help please....

Rick


_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.