09-07-2010 10:44 AM
Hi,
As in my Subject line, I am not bale to comprehend the reason. On what base should I suggest the developers to make the changes in code. I have analysed it in SE30.
Select Single * took 19.450.230.000 microseconds.
select * took 713.955 microseconds seconds.
CRMV_LINKORGMAN is view, as you might know.
Regards,
Chitwanjit
09-07-2010 10:53 AM
Hello.
Have you tried executing more than once?
Have you tried executing them in the opposite sequence (SELECT * first) ? (the first one you measure will often be slower)
What is your complete select?
Regards,
Rui Dantas
09-07-2010 10:53 AM
Hello.
Have you tried executing more than once?
Have you tried executing them in the opposite sequence (SELECT * first) ? (the first one you measure will often be slower)
What is your complete select?
Regards,
Rui Dantas
09-07-2010 10:56 AM
Here is the complete select.
data itab type standard table of CRMV_LINKORGMAN.
data wa_link type CRMV_LINKORGMAN.
select * from CRMV_LINKORGMAN INTO table itab
where SALES_ORG = 'O 50002332' .
09-08-2010 9:41 AM
And have you tried executing more than once, and executing them in the opposite sequence (SELECT * first) ?
09-09-2010 3:34 PM
Hi Chitwanjit,
Probably you are not using the fully primary key to use the SINGLE instruction (it work's but it wasn't designed for retrieve one THE record, for this the where clause must reach a unique index).
Since this is a view, this uniquecy must be checked according the database union on view.
BTW: Please answer Rui's question, it's important for understanding caching.
Regards, Fernando Da Ró
09-09-2010 5:01 PM
Yes,
I have tried in diff sequence and tried more than once. I think the point made earlier that Primary keys are not included in the where clause, make it perform in the current manner. Anyhow, The View is using two very huge tables and I have decided to replace the same with the JOIN on two tables which has given marked improvement in performance.