Experiment on performance: SELECT SINGLE vs FOR ALL ENTRIES, secondary index access

 

Experiment on performance series

Part I: SELECT SINGLE vs FOR ALL ENTRIES

Part II: SELECT SINGLE vs FOR ALL ENTRIES, secondary index access

I believe our previous test on SELECT SINGLE vs FOR ALL ENTRIES did not surprise many of you because I see a tendency towards FOR ALL ENTRIES in programs I encounter. In previous scenario, we were able to access the search table with primary key but this may not be the case every time. Let’s see what happens if we could not access the search table with primary key, but with secondary index. Continue reading “Experiment on performance: SELECT SINGLE vs FOR ALL ENTRIES, secondary index access”

Experiment on performance: SELECT SINGLE vs FOR ALL ENTRIES

Experiment on performance series

When all business requirements are met in a development, customer complaints always come down to performance. “Can’t this run any faster?” we always hear. Performance, in a technical point of view, is a broader concept that not just includes execution time, but also optimal use of system resources like memory and network load.  But powerful hardware of our age and requirement of end user satisfaction leaves us with a single option to have execution time (or speed) as the top priority performance aspect. So I will experiment on some known techniques for database access and internal table processing, and share the results here. Continue reading “Experiment on performance: SELECT SINGLE vs FOR ALL ENTRIES”