RetrieVe will use an index if it can, regardless of the order of the selection criteria (& if not select list is already active). RetrieVe will now do intersections of index reults if 2 indexed selection criteria are specified.
I'm not sure when or how good it does that.
NO.OPTIMIZE can override these attempts by RetrieVe.
NO.INDEX will prevent indexes being used.

On 10/25/2011 5:00 PM, Steve Romanow wrote:
I think we are bike-shedding this now :)

I seem to recall that if the indexed field is _before_ the non indexed
field, its benefit is not lost.  I have not looked close at that in a
long time.

On Tue, Oct 25, 2011 at 5:42 PM, Woodward, Bob
<>  wrote:
Add a second selection criteria and the benefit of the index is washed

-----Original Message-----
[] On Behalf Of Charles
Sent: Tuesday, October 25, 2011 2:39 PM
To: U2 Users List
Subject: Re: [U2] UniBasic Question

True on UV, too.
Compare output of these using EXPLAIN keyword:
LIST FILE WITH indexed_field = "soemthing"  EXPLAIN
LIST FILE WITH indexed_field = "soemthing"  EXPLAIN  NO.INDEX

Or forget EXPLAIN, but do it with a large file and notice the speed

On 10/25/2011 4:29 PM, wrote:
I don't know if I agree that SELECT is faster.  If you are using
indexed fields, SELECT is definitely not the good choice.
Are you saying that when there is an index, the system does not need
read the record at all?  It just gets the SELECT list from the index?
this only true in Unidata?

U2-Users mailing list

Reply via email to