But you are potentially reducing your input set for the 2nd criteria by a large margin correct?
I've never considered alt key + non-indexed usage to create disk thrash. When you select on an alternate key index, you are reading the file, but (in Udt at least) an X_myfile binary file. So you are doing a direct read for the matching keys. It has no knowledge of the file layout. On Tue, Oct 25, 2011 at 6:01 PM, Wjhonson <wjhon...@aol.com> wrote: > > Yes yes and no. > > If you execute a SSELECT on an indexed field, and don't specify NO.INDEX and > do NOT refer at all to any other fields in the file, then index does NOT read > the record to see if it even actually exists. It just retrieves the list of > keys from the index. > > If you specific a SSELECT on an indexed field and ALSO specify some other > field criteria, then the select is *supposed* to use the index field FIRST to > retrieve the list of keys and ONLY THEN read each record to see whether it > matches the other criteria. So the "first pass" if you will should be > lightning fast, but then IF your other criteria makes it traverse the > majority of the file you are in for big Trouble with a "T" that rhymes with > "P" that stands for "Pool". > > The reason you are in for trouble in this last case, is that traversing the > majority of the file causes Disk Thrashing which is bad very bad very very > bad. It causes this because you are forcing the system to reference the > records out-of-disk-order. So it's jumping, jumping, jumping all over the > disk in a helter skelter summer swelter. > > You want to avoid that. > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
