I knew the index dictionary was virtual - I was wondering if the
clientno etc were maybe translates or something else that that the
select query might use to invalidate the index. I think the only trouble
we ever had with UD indices what that it wasn't actually built - but
your list.index showed it as being built.
Never really had to test if the index was used - it was always way
faster. It would be interesting to know how long an un-indexed select
would take on the two boxes.
The only thing I've had to do with and index is delete and re-create it.
Make sure you DELETE-INDEX GLPOST ALL, then make sure the X_GLPOST file
has been removed. Then re-create and re-build the index - making sure no
one is accessing the file at the time. I have seen an index that was
created while the file was actively being updated do some strange
things.
hth
Colin Alfke
Calgary Canada
-----Original Message-----
From: Bill Haskett
Colin:
The dictionary is virtual. It's code is:
002: OCONV( CLIENTNO, 'MR%4' ) : YRMO_PSTD : OCONV( ACCTNO, 'MR%6' ) :
OCONV( @ID, 'MR%8' )
CLIENTNO, YRMO_PSTD, and ACCTNO are [D]irect dictionaries with no
conversions (just raw data).
How does one go about testing if indexing is used in a query? I'm sure
it's not, for this query, because of the time differences between D3 (on
an old P-III) and UD (on a new Xeon); D3 being much faster on an index
select.
The output looks like:
060520030800307000583056
When I use a SETINDEX, READXFWD, READXBCK in BASIC I get to the top and
bottom instantaneously. So, I'm thinking a SELECT using the index
should also be almost instantaneous for such a relatively small number
of items.
Thanks,
Bill
>-----Original Message-----
>From: colin.alfke
>
>Bill;
>
>Any chance that any of the parts of the index are translated or does a
>subroutine call?
>
>I always had more trouble with D3 indices than with UD. We don't use
>sort.type
>2 though. A quick test showed no difference though. I also liked the
>thought that it may be trying to use a pattern match than a string.
>
>HTH
>Colin Alfke
>Calgary Canada
>
>________________________________
>
>From: Bill Haskett
>
>
>>>
>>>I forgot to add:
>>>
>>>UD v7.1.9
>>>SORT.TYPE = 2 (forced to do this because of improper sorting in
>>>SORT.TYPE 0)
>>>
>>>Bill
>>> _____
>>>
>>>From: Bill Haskett >>Sent: Wednesday, August 15, 2007 12:25 PM
>>>
>>>I'm having difficulty ensuring the indexes are used in UniQuery. In
>>>D3, if I do the
>>>following:
>>>
>>>26 Demo (0)-> SELECT GLPOST WITH INDEX_2 = "0605]"
>>>
>>>[4041] 21791 items selected.
>>>
>>>...it would always use the index if one existed. I knew the
>>index was
>>>used because the selected message didn't include the " out of {n}
>>>items." string appended to the end (e.g. "[404] 21791 items selected
>>out of 884083 items.").
>>>
>>>On an old P3 server, running D3, with 50 people on it, 512Mb memory
>>>(shared by Linux), this took about 9 seconds. On a new Intel Xeon
>>>server, running UniData,
>>with
>>>5 people on it, 2Gb memory, Windows 2K3, this took about 19 seconds.
>>>
>>>In UniData, I notice some selects are taking significantly
>>longer than
>>>in D3. I've properly indexed the file, I can test that
>>indexing works
>>>by using a BASIC program than does the usual SETINDEX, READXFWD,
>>>READXBCK, etc. The index looks
>>>like:
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
