Performance Improvement possible due to replacing delete-command?

[carsten_klatt]

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

[Former Member]

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.

[volker_borowski2]

How about putting

akont not equal space

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

Volker

[Former Member]

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,

m.

[yuri_ziryukin]

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

[Former Member]

>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.