Hi all
I have already posted a detailed question about the issue we are having in the SAP Oracle section (https://scn.sap.com/thread/3642137) which has had some discussion and has delved into the workings of Oracle and execution plans.
What I want to do here is go down a different path, and ask here a more generic question about how TREX works, or at least, the way TREX/SES works when activated for VMS/transaction VELO.
My understanding was that when a user runs a search in VELO with TREX set up, that the selection criteria is effectively passed to TREX, which then goes ahead and checks its index and returns vehicle IDs (VGUID) to the transaction. A modified SAP/SQL query is then ran against the SAP system, making use of these vehicle IDs and thus speeding up the search.
So far right?
However, it seems that although the SQL ran does appear to now contain the relevant VGUIDs (from tracing we see that with TREX disabled VGUID does not appear in the SQL) it also contains all (except one) of the original fields/search criteria from the initial search.
Surely it doesn't need this? As TREX has returned the relevant VGUIDs, matching the users selection criteria, the SQL search should purely search on VGUID - right?
As it is, those extra criteria, which includes a huge in-list of material numbers, are slowing down the search - it takes over 8 times longer with TREX enabled!
Is TREX configured incorrectly - can you configure somewhere what exactly TREX returns? Or is this 'hard coded' and it more likely a bug within the code/VELO transaction?
Thanks
Ross