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
<bob_woodw...@k2sports.com> wrote:
Add a second selection criteria and the benefit of the index is washed
out.
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles
Stevenson
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
differnce.
On 10/25/2011 4:29 PM, charles_shaf...@ntn-bower.com 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
to
read the record at all? It just gets the SELECT list from the index?
Is
this only true in Unidata?
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
