I believe that it is incorrect that it will intersect indexes.
I understand that some people think this might be preferable, but I do not
believe this logic has ever been coded in.
From: Charles Stevenson <stevenson.c...@gmail.com>
To: U2 Users List <email@example.com>
Sent: Tue, Oct 25, 2011 3:08 pm
Subject: Re: [U2] UniBasic Question
RetrieVe will use an index if it can, regardless of the order of the
election criteria (& if not select list is already active).
etrieVe will now do intersections of index reults if 2 indexed
election criteria are specified.
'm not sure when or how good it does that.
O.OPTIMIZE can override these attempts by RetrieVe.
O.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
> -----Original Message-----
> From: u2-users-boun...@listserver.u2ug.org
> [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?
2-Users mailing list
U2-Users mailing list