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
On Tue, Oct 25, 2011 at 5:42 PM, Woodward, Bob
Add a second selection criteria and the benefit of the index is washed
[mailto:u2-users-boun...@listserver.u2ug.org] 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, 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
read the record at all? It just gets the SELECT list from the index?
this only true in Unidata?
U2-Users mailing list