Building a temporary, ordered subset of a table can speed up a query. It can help to avoid multiple-sort operations and can simplify the work of the optimizer in other ways.
For example, suppose your application produces a series of reports on customers who have outstanding balances, one report for each major postal area, ordered by customer name. In other words, a series of queries occurs, each of the following form (using hypothetical table and column names):
SELECT cust.name, rcvbles.balance, ...other columns...
FROM cust, rcvbles
WHERE cust.customer_id = rcvbles.customer_id
AND rcvbls.balance > 0
AND cust.postcode LIKE '98_ _ _'
ORDER BY cust.name
This query reads the entire cust table. For every row with the specified postal code, the database server searches the index on rcvbles.customer_id and performs a nonsequential disk access for every match. The rows are written to a temporary file and sorted. For more information on temporary files, see Configuring Dbspaces for Temporary Tables and Sort Files.
This procedure is acceptable if the query is performed only once, but this example includes a series of queries, each incurring the same amount of work.
An alternative is to select all customers with outstanding balances into a temporary table, ordered by customer name, as the following example shows:
SELECT cust.name, rcvbles.balance, ...other columns...
FROM cust, rcvbles
WHERE cust.customer_id = rcvbles.customer_id
AND cvbls.balance > 0
INTO TEMP cust_with_balance
You can then execute queries against the temporary table, as the following example shows:
SELECT * FROM cust_with_balance WHERE postcode LIKE '98_ _ _' ORDER BY cust.name
Each query reads the temporary table sequentially, but the table has fewer rows than the primary table.
Enterprise Edition Home | Express Edition Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]