Skip to main content

READ vs SQL SELECT, A Quick Performance Test


With no doubt, SQL is the advanced and efficient way for operations (Read, Write, Update or Delete) on Tables (or Files) on IBM i. 

With the use of Embedded SQL programming (SQLRPGLE), it is efficient to use SELECT to read the data from a table compared to using READ. 

Here is the result from a quick performance test between READ and SELECT to read One million records from a table.

Below are few points to consider about the test before we see the results. 
  • Created Physical File (using DDS) for the use in RPGLE with READ Operation. 
  • Created Table from SQL Session for the use in SQLRPGLE with SQL SELECT Operation.
  • Both the files has same number of fields, length and same number of records.
  • Both Programs are called from a new Interactive Session immediately after login.
Let's see the code used to create File/Table and Program. 

Physical File (PPTESTFILE):


Inserted one million records (same data) to both the files. And, Table is occupying less size compared to Physical File

Size of Physical File:

Record Length - 40, Total Records - 1,000,000, Size of Physical File - 64,008,192 Bytes

Size of Table:

Record Length - 40, Total Records - 1,000,000, Size of Physical File - 41,951,232 Bytes

Below is the code used for both READ & SELECT. 



Now, coming to the Results, Program with SELECT operation has run in in 30% (approx) less time than with READ (70% of READ).

Program with READ took about 9 seconds to read one million records. 

Program with SELECT took about 6 seconds to read one million records. 

So, It is efficient both in terms of Processing time and Storage to use SQL in place of READ wherever possible. 

Again, Is there a better way of doing this with SQL? Yes, Instead of Fetching one record every time, We can Fetch multiple records into Data Structure and loop through Data Structure for accessing the data. 

This has run > 60% faster than SQL SELECT example listed above. Click Here to see more details on this test.


  1. This is not a valid performance comparison. The RPG READ example reads the table by key, whereas the SQL SELECT example doesn't.

    You might try adding an ORDER BY clause to the SQL SELECT, or change the RPG READ to use BLOCK mode. Then show us the results.

    1. Hi Nathan,

      Thanks for Pointing. I have added ORDER BY clause to SQL SELECT and ran the test once again. Results are exactly same as it was with out ORDER BY.

      Updated the Results above.


  2. Replies
    1. Yes Manu, Test was done on V7R2.

      However, I am not anticipating many changes for any of the latest versions (V7R3 or V7R4).


  3. isn't the index stored separately from the table? If so, the table's size would need to include the index's size to be an equal comparison of storage.

    1. Hi,

      Table was created with Unique Key Constraint and No separate Index has been created.


  4. La prueba no es convincente, esos 3 segundos pueden indicar otra cosa, ahora tripliquen los datos a 3millones y revisen si el tiempo se triplicó, así si.

    1. Hi,

      I have run the test with 3 million records as suggested and the time difference is now about 17 seconds. Below is for your reference.

      DSPLY Start: 10.44.43 End: 10.45.13 Records: 3000000 //30 Seconds

      DSPLY Start: 10.46.22 End: 10.46.35 Records: 3000000 //13 Seconds

      DSPLY Start: 10.47.18 End: 10.47.22 Records: 3000000 //4 Seconds



Post a Comment

Popular posts from this blog

All about READ in RPGLE & Why we use it with SETLL/SETGT?

READ READ is one of the most used Opcodes in RPGLE. As the name suggests main purpose of this Opcode is to read a record from Database file. What are the different READ Opcodes? To list, Below are the five Opcodes.  READ - Read a Record READC - Read Next Changed Record READE - Read Equal Key Record READP - Read Prior Record READPE - Read Prior Equal Record We will see more about each of these later in this article. Before that, We will see a bit about SETLL/SETGT .  SETLL (Set Lower Limit) SETLL accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Corresponding Record (or Next Record if exact match isn't found).  SETGT (Set Greater Than) SETGT accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Next Record (Greater Than the Key value). Syntax: SETLL SEARCH-ARGUMENTS/KEYFIELDS FILENAME SETGT  SEARCH-ARGUMENTS/KEYFIELDS FILENAME One of the below can be passed as Search Arguments. Key Fiel

What we need to know about CHAIN (RPGLE) & How is it different from READ?

CHAIN READ & CHAIN, These are one of the most used (& useful) Opcodes by any RPG developer. These Opcodes are used to read a record from file. So, What's the difference between CHAIN & READ?   CHAIN operation retrieves a record based on the Key specified. It's more like Retrieving Random record from a Database file based on the Key fields.  READ operation reads the record currently pointed to from a Database file. There are multiple Opcodes that start with READ and all are used to read a record but with slight difference. We will see more about different Opcodes and How they are different from each other (and CHAIN) in another article. Few differences to note.  CHAIN requires Key fields to read a record where as READ would read the record currently pointed to (SETLL or SETGT are used to point a Record).  If there are multiple records with the same Key data, CHAIN would return the same record every time. READE can be used to read all the records with the specified Ke

Extract a portion of a Date/Time/Timestamp in RPGLE - IBM i

%SUBDT Extracting Year, Month, Day, Hour, Minutes, Seconds or Milli seconds of a given Date/Time/Timestamp is required most of the times.  This can be extracted easily by using %SUBDT. BIF name looks more similar to %SUBST which is used to extract a portion of string by passing from and two positions of the original string. Instead, We would need to pass a value (i.e., Date, Time or Timestamp ) and Unit (i.e., *YEARS, *MONTHS, *DAYS, *HOURS, *MINUTES, *SECONDS or *MSECONDS) to %SUBDT.  Valid unit should be passed for the type of the value passed. Below are the valid values for each type. Date - *DAYS, *MONTHS, *YEARS Time - *HOURS, *MINUTES, *SECONDS Timestamp - *DAYS, *MONTHS, *YEARS, *HOURS, *MINUTES, *SECONDS, *MSECONDS Syntax: %SUBDT(value : unit { : digits { : decpos} }) Value and Unit are the mandatory arguments.  Digits and Decimal positions are optional and can only be used with *SECONDS for Timestamp. We can either pass the full form for the unit or use the short form. Below i