How does select stmt with for all entries uses Indexes

Question

Hello all,
I goes through a number of documents but still confused how does select for all entries uses indexes if fields are not in sequences. i got pretty much the same results if i take like two cases on Hr tables HRP1000 and HRP1001(with for all entries based upon hrp1000). Here is the sequence of index fields on hrp1001 (MANDT, OTYPE, OBJID, PLVAR, RSIGN, RELAT, ISTAT, PRIOX, BEGDA, ENDDA, VARYF, SEQNR). in second case objid field is in sequence as in defined Index but i dont see significant increase in field even though the number of records are around 30000. My question is does it make a differrence to use field sequence (same as in table indexes) in comparison to redundant field sequence (not same as defined in table indexes), secondly how we can ge tto know if table index is used in Select for entries query i tried Explain in ST05 but its not clear if it uses any index at all in hrp1001 read.
here is the sample code i use to get test results.
test case 1
REPORT  zdemo_perf_select.
DATA: it_hrp1000 TYPE STANDARD TABLE OF hrp1000 WITH HEADER LINE.
DATA: it_hrp1001 TYPE STANDARD TABLE OF hrp1001 WITH HEADER LINE.
DATA: it_hrp1007 TYPE STANDARD TABLE OF hrp1007 WITH HEADER LINE.
DATA: it_pa0000 TYPE STANDARD TABLE OF pa0000 WITH HEADER LINE.
DATA: it_pa0001 TYPE STANDARD TABLE OF pa0001 WITH HEADER LINE.
DATA: it_pa0002 TYPE STANDARD TABLE OF pa0002 WITH HEADER LINE.
DATA: it_pa0105_10 TYPE STANDARD TABLE OF pa0105 WITH HEADER LINE.
DATA: it_pa0105_20 TYPE STANDARD TABLE OF pa0105 WITH HEADER LINE.
DATA: t1 TYPE timestampl,
      t2 TYPE timestampl,
      t3 TYPE timestampl 
SELECT * FROM hrp1000 CLIENT SPECIFIED  INTO TABLE it_hrp1000 bypassing buffer
            WHERE mandt EQ sy-mandt AND
                  plvar EQ '01' AND
                  otype EQ 'S'AND
                  istat EQ '1' AND
                  begda <= sy-datum AND
                  endda >= sy-datum AND
                  langu EQ 'EN'.
GET TIME STAMP FIELD t1.
SELECT * FROM hrp1001 CLIENT SPECIFIED INTO TABLE it_hrp1001 bypassing buffer
            FOR ALL ENTRIES IN it_hrp1000
             WHERE mandt EQ sy-mandt AND
                    otype EQ 'S' AND
*                    objid EQ it_hrp1000-objid and
                    plvar EQ '01' AND
                    rsign EQ 'B' AND
                    relat EQ '007' AND
                    istat EQ '1' AND
                    begda LT sy-datum AND
                    endda GT sy-datum and
                    sclas EQ 'C' and
                    objid EQ it_hrp1000-objid.
*                    %_hints mssqlnt 'INDEX(HRP1001~0)'.
*delete it_hrp1001 where sclas ne 'C'.
GET TIME STAMP FIELD t2.
t3 = t1 - t2.
WRITE: 'Time taken - ', t3.
test case 2
REPORT  zdemo_perf_select.
DATA: it_hrp1000 TYPE STANDARD TABLE OF hrp1000 WITH HEADER LINE.
DATA: it_hrp1001 TYPE STANDARD TABLE OF hrp1001 WITH HEADER LINE.
DATA: it_hrp1007 TYPE STANDARD TABLE OF hrp1007 WITH HEADER LINE.
DATA: it_pa0000 TYPE STANDARD TABLE OF pa0000 WITH HEADER LINE.
DATA: it_pa0001 TYPE STANDARD TABLE OF pa0001 WITH HEADER LINE.
DATA: it_pa0002 TYPE STANDARD TABLE OF pa0002 WITH HEADER LINE.
DATA: it_pa0105_10 TYPE STANDARD TABLE OF pa0105 WITH HEADER LINE.
DATA: it_pa0105_20 TYPE STANDARD TABLE OF pa0105 WITH HEADER LINE.
DATA: t1 TYPE timestampl,
      t2 TYPE timestampl,
      t3 TYPE timestampl 
SELECT * FROM hrp1000 CLIENT SPECIFIED  INTO TABLE it_hrp1000 bypassing buffer
            WHERE mandt EQ sy-mandt AND
                  plvar EQ '01' AND
                  otype EQ 'S'AND
                  istat EQ '1' AND
                  begda <= sy-datum AND
                  endda >= sy-datum AND
                  langu EQ 'EN'.
GET TIME STAMP FIELD t1.
SELECT * FROM hrp1001 CLIENT SPECIFIED INTO TABLE it_hrp1001 bypassing buffer
            FOR ALL ENTRIES IN it_hrp1000
             WHERE mandt EQ sy-mandt AND
                    otype EQ 'S' AND
                    objid EQ it_hrp1000-objid and
                    plvar EQ '01' AND
                    rsign EQ 'B' AND
                    relat EQ '007' AND
                    istat EQ '1' AND
                    begda LT sy-datum AND
                    endda GT sy-datum and
                    sclas EQ 'C'." and
*                    objid EQ it_hrp1000-objid.
*                    %_hints mssqlnt 'INDEX(HRP1001~0)'.
*delete it_hrp1001 where sclas ne 'C'.
GET TIME STAMP FIELD t2.
t3 = t1 - t2.
WRITE: 'Time taken - ', t3.

Answer 1

Mani wrote:
Thank you for your answer, its very helpful but i am still nor sure how does parameter rsdb/max_blocking_factor affect records size.
Hi,
The blocking affects the size of the statement and the memory structures for returning the result.
So if your itab has 500 rows and your blocking is 5, the very same statement will be executed 100 times.
Nothing good or bad about this so far.
Assume, your average result for an inlist 5 statement is 25 records with an average size of 109 bytes.
You average result size will be 2725 byte plus overhead which will nearly perfectly fit into two 1500 byte ethernet frames.
Nothing to do in this case.
Assume your average result for an inlist 5 statement is 7 records with an average size of 67 bytes.
You average result size will be ~ 470 byte plus overhead which will only fill 1/3 of a 1500 byte ethernet frame.
In this case, setting the blocking to 12 ... 15 will give you 66% network transfer performance gain,
and reduces the number of calls to the DB by 50%, giving additional benefit.
Now this is an extreme example. The longer the average row length is, the lower will be the average loss in the network.
You have the same effects in memory structures, but on that layer you are fighting single micro seconds instead of
hundreds of these, so in real life it is rarely measurable.
Depending on table-statistics, oracle might decide for short inlists to use a concatanation instead of an inlist.
This is supposed to be more costy, but I never had a case where I could proove a big difference.
Values from 5 to 15 for blocking seem to be ok for me. If you have special statements in customer coding,
it #might# be benefitial to do the mentioned calculations and do some network tracing to see if you can squeeze your
network efficiency by tuning the blocking.
If you have jumbo frames enabled, it might be worth to be analyzed as well.
If you are only on a DB-CI system that is loopback connected to the DB, I doubt there might be a big outcome.
Hope this helps
Volker