Philip: I agree, what you have observed is strange. The name of tag should not matter, only the expression of what is indexed.
Unless the first index had another clause, like UNIQUE or FOR .NOT. DELETED() in the tag creation, the first tag should have worked for you. The other possibility is that the original tag had some corruption, or the index needed to be rebuilt. If the index was created a long time ago, and a lot of records added since then, the index could be bloated, fragmented across a a lot of file fragments, which sometimes a PACK, REINDEX or a clean re-creation would resolve. On Fri, Jun 26, 2015 at 12:50 PM, Philip Borkholder <[email protected]> wrote: > Thank you for the responses: > > What I find strange though, and the reason I posted, is that the JOIN field > DID have an index TAG in the CDX with a TAG name that differed from the > field, and the Query was slow. > > Once I added an additional Index tag, on the same field, with a TAG name > that equaled the field, > the query ran faster... very strange. > > -Philip > > > On 6/26/2015 12:33 PM, Fred Taylor wrote: >> >> Yes, that's exactly correct. For Rushmore to kick in, the left side of >> your condition must match a tag's fields. The tag name is irrelevant. >> >> So in your example, TABLEA must have an index on FGITEM. The tag name >> does >> not matter. >> >> >> Fred >> >> On Fri, Jun 26, 2015 at 9:08 AM, Philip Borkholder <[email protected]> >> wrote: >> >>> Hello all, >>> >>> I know that Rushmore tech comes into play when you JOIN tables using >>> fields that have index tags in their respective tables. >>> >>> However, does the tag have to match the name of the actual field being >>> indexed? >>> Reason I ask, in an app I support, performance was slow when joining two >>> tables together on one key field. >>> >>> Let's say the field is: >>> FGITEM >>> The index tag is just ITEM >>> >>> The Join statement had: >>> >>> SELECT tableA.*, tableB.descrip FROM tableA INNER JOIN tableB on >>> tableA.FGITEM = tableB.ITEM >>> >>> Once I added a new index TAG to tableA >>> FGITEM tag FGITEM >>> >>> The query ran much faster. >>> >>> Does this make sense or am I misunderstanding it? >>> >>> Thank you, >>> Philip Borkholder >>> Vicksburg, MI >>> ____________________________________________________________ >>> Old School Yearbook Pics >>> View Class Yearbooks Online Free. Search by School & Year. Look Now! >>> http://thirdpartyoffers.netzero.net/TGL3241/558d7928daeb179283574st04duc >>> [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cacw6n4ukz+jrmzerbgeiusdu4zzsfwcyel2e64dmy8ruabq...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
