Faster, Better Queries with Encoded Vector Indexes. By Paul J. Sgroi

Transcription

1 Faster, Better Queries with Encoded Vector Indexes By Paul J. Sgroi

2 Faster, Better Queries with Encoded Vector Indexes Author: Paul J. Sgroi A few years ago, IBM Research came up with a new type of index called an Encoded Vector Index (EVI). The main benefits of using EVIs is that they takes less space than a traditional bitmap index and they are noticeably faster for certain types of queries. For more details on how and why EVIs work, check out this link from IBM. 1.ibm.com/servers/enable/site/bi/evi.html When you run a Query or a SQL Select, the UDB/400 query optimizer kicks in. It goes out and finds the best possible access of the files based on your selection and sort criteria. When you ve tried to do an ISQL Select or you hit [F5] on QUERY/400, I m sure you ve seen those annoying Query running. Building access path for file SOMEFILE in SOMELIBRARY statement at the bottom of your screen. With EVIs, you create a new set of logical files on your computer. Each new logical file is a 1 key access path. The 1 key value ensures that the size of the file on the system is small or compact and reduces the likelihood that the annoying building access path statement will pop up. At this point, I need to clarify where you can and cannot use EVIs. You cannot use EVIs with traditional High Level Language (HLL) I/O. So even though EVIs are useful, you re won t be able to use RPG s setll, chain, or reads against them. So, why even bother with EVIs? Here s an example of where an EVI is useful. Suppose your iseries database is available on your company s intranet. In the executive area of the site, VIPs can look up customer sale summaries. When the VIP clicks her submit button, she expects the Select statement running behind the scenes to rip through the database and come back with her requested information quickly. She doesn t want to wait around or see an annoying message. Testing 1, 2, 3 Last semester, I was given the task of developing an on line course at my local community college for an intro to SQL/400 course. I was working on a lesson on SQL Indexes and did a test to show how much faster a query can be with just the mere presence of EVIs using Interactive SQL. First, I created a new non keyed table on the college s 50 S running V5R1. I called this table CUSTSUM and filled it with 3 million records (Figure 1). Without any natural keys, any Select/Order By against the CUSTSUM file in ISQL will cause that annoying building access path message. Figure 1: Create Table statements for CustSum

3 Next, I ran an ISQL Select statement over the CUSTSUM file (Figure 2) to give me a small list of Eastern and Western customers whose sales were between $1, and $1, Out of 3 million records, the result of the query is only 26. It took the query optimizer approximately two minutes to build the temporary access path I needed and display the information. (Meanwhile, I m picturing an irate Sales Director waiting for the query results for those lousy 26 customers!) Figure 2: ISQL Select/Order By

4 Then I created a traditional index (Figure 3) with the needed keys and ran the statement shown in Figure 2. This time, the annoying Query running. Building access path for file CUSTSUM in PSGROI message went away. The query also ran faster it ran a little over 1 minute. This query was an improvement, but it was still slow. Figure 3: Create Index statement over CustSum

5 Finally, I deleted the previous traditional index and created two separate EVIs (Figure 4) over CUSTSUM. I created one EVI for each possible searchable key. Then I ran the SQL Select statement in Figure 2 again. This time, the result of 26 customers came back in less than 6 seconds. After this testing, I was convinced that EVIs are the way to go. (Think of the possibilities!) Figure 4: Create EVIs over CustSum

6 However, don t forget that you can t directly access an EVI (see Figure 5). If you currently have embedded SQL, OPNQRYFs, and especially HLL programs accessing specific logical files, you don t want to replace them all right away. Figure 5: Trying to access an EVI directly

7 Paul J. Sgroi is an instructor at Luzerne County Community College in Nanticoke, PA and a Senior Programmer/Analyst at Penn Software & Technology Services, Inc. in Wilkes Barre, Pa. He can be reached at pauljsgroi@aol.com.