topic Re: Performance Improvement possible due to replacing delete-command? in Application Development and Automation Discussions

Performance Improvement possible due to replacing delete-command?

carsten_klatt — Fri, 30 Sep 2011 09:21:50 GMT

Dear Specialists,

has anybody of you an idea how i still could improve the performance of the following part of a program?

I was thinking if it could be helpful to avoid the deletion at the end of the pasted coding somehow...

DATA gt_knb1 TYPE HASHED TABLE OF t_knb1 WITH UNIQUE KEY bukrs akont.

IF s_bukrs[] IS INITIAL.

SELECT akont COUNT(*) AS count FROM knb1

INTO CORRESPONDING FIELDS OF TABLE gt_knb1 "#EC CI_NOFIRST

GROUP BY akont. "#EC CI_NOWHERE

ELSE.

SELECT bukrs akont COUNT(*) FROM knb1 INTO TABLE gt_knb1"#EC CI_NOFIRST

WHERE bukrs IN s_bukrs

GROUP BY bukrs akont. "#EC CI_NOWHERE

ENDIF.

DELETE gt_knb1 WHERE bukrs IN s_bukrs AND akont = space.

Thanks a lot in advance

Best regards

Carsten

Re: Performance Improvement possible due to replacing delete-command?

Former Member — Fri, 30 Sep 2011 13:42:49 GMT

There are bunch of things you can do to improve performance in it.

Don't use count, group by...

You are fetching only couple fiels, use target structures with those fields and avoid using into corresponding

In delet statement write the space condition first and then IN range.

Re: Performance Improvement possible due to replacing delete-command?

volker_borowski2 — Fri, 30 Sep 2011 15:58:14 GMT

How about putting

akont not equal space

into the WHERE clause of the SELECTs and not doing the delete at all ?

Volker

Re: Performance Improvement possible due to replacing delete-command?

Former Member — Fri, 30 Sep 2011 16:52:44 GMT

Hi,

How huge is your table approximately? The best idea would be to remove that COUNT and GROUP but I guess they are useful to you...The ugliest part for me anyway is this

INTO CORRESPONDING FIELDS OF

... I think a dynamic internal table could help so that gt_knb1 fits exactly to the fetched rows.

Also, as Volker says, that DELETE is useless...

Hope it helps a bit,

kr,

Re: Performance Improvement possible due to replacing delete-command?

yuri_ziryukin — Tue, 04 Oct 2011 09:02:06 GMT


Hi,
> 
>...The ugliest part for me anyway is this INTO CORRESPONDING FIELDS OF
... I think a dynamic internal table could help so that gt_knb1 fits exactly to the fetched rows.
> 
> kr,
> m.

Hello all,

please note, the "CORRESPONDING FIELDS" is not so relevant nowadays. Few milliseconds are not going to change a picture.

Refer to this thread:

Please stop recommending it in EACH AND EVERY thread appearing in this forum.

The correct answer is given by Volker above.

And by the way, are you really sure that your problem is in the DELETE statement? I would actually suspect the SELECT to be a time-consumer.

Regards,

Yuri

Re: Performance Improvement possible due to replacing delete-command?

Former Member — Wed, 05 Oct 2011 08:29:03 GMT

>The ugliest part for me anyway is this INTO CORRESPONDING FIELDS OF

.... a long living myth and completely outdated. The INTO CORRESPONDING disappears in the variation of the SELECTs performance.

10 points should not be given ... rather be deduced

First step move the DELETE inside the IF-clause, then 2 different DELETEs are necessary!

Second why can the DELETE condtion not be added to the WHERE-clause. The not condiitions do not help with the index, but without WHERE you will also not use an index! Not transferring data from the database helps much more than a delete on ABAP side.