DOCSLIB.ORG

Effectively Using the Indices in an Oracle® Database with SAS® Kenneth W

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Effectively Using the Indices in an Oracle® Database with SAS® Kenneth W NESUG 17 Posters Effectively Using the Indices in an Oracle® Database with SAS® Kenneth W. Borowiak, Howard M. Proskin & Associates, Inc. Abstract Key features of a database are indices, which can substantially aid in reducing the time it takes for queries submitted against the database to run. However, making effective use of them is a non-trivial task. This paper outlines how to identify table indices, create a query plan to see if and what indices are being used, create table indices and provide hints to the query optimizer in order to fine-tune queries submitted against an Oracle database with SAS. Introduction Important components of any medium to large sized database are indices (plural for index)1. Indices are guides to where the values of variables are located in the database. Making effective use of table indices when querying a database can substantially reduce the time it takes for queries to run. To aid in the fine-tuning of queries submitted against an Oracle database through SAS, this paper outlines how to: • identify table indices, • create a query execution plan to see if and what indices are being used, • provide hints to the query optimizer, and • create table indices. The obvious target audience of this paper is those SAS users who need to extract data from an Oracle database. However, SAS data sets can also be buttressed with indices. Therefore, the concepts presented in this paper (but not necessarily the code) can be useful for any SAS user interested in making effective use of indices. Preliminaries The values of the user id, password and path needed to make the connection to the Oracle tables will be embedded in the macro variables me, myob, and lesstaken, respectively. Oracle tables will be written in mixed-case and fields in lower-case; both will be in Courier New font. An Index Paradigm An index is a guide to where the values of a variable or group of variables reside in a database. A collection of table indices can be likened to an index at the end of a textbook. When you want to find information on a particular topic in the book you could look up the word in index and find what pages related information is located. The textbook index 1 Other important considerations are database design and partitioning. 1 NESUG 17 Posters paradigm of database indices just presented will continue to be built upon throughout the paper. What Indices Exist? Database indices have other similar characteristics to a textbook index. First, not every word that appears in a textbook will appear in the index because the numerous words or topics to keep track of would too cumbersome. Many words would not be very informative, such as the word ‘the’. Similarly, not every variable in a database should be indexed because resources are needed to create, store and maintain them. There are a couple of ways to ascertain the existence of table indices in an Oracle database. The database administrators may have readily accessible metadata on the available table indices, possibly in an HTML format. Oracle also provides a series of metadata or system tables. The All_Ind_Columns table contains information on which variables (found in the column_name field) are indexed (found in the index_name field). The following scripts can be submitted to extract information on table indices and indexed columns2: /* Identifying table indices */ libname Orasys oracle user=&me password=&myob path=&lesstaken schema=SYS; proc sql; /* Pass-Through method #1 */ connect to oracle (user=&me password=&myob path=&lesstaken); create table <table name> as select * from connection to oracle (select index_name, column_name from All_Ind_Columns); disconnect from oracle; /* or */ /*Pass-Through method #2-Requires privileges to create Oracle tables */ connect to oracle (user=&me password=&myob path=&lesstaken); execute ( create table <table name> as select index_name, column_name from All_Ind_Columns) by oracle; disconnect from oracle; /* or */ /* Accessing the metadata w/ a libref */ create table <table name> as select index_name, column_name from Orasys.All_Ind_Columns; quit; 2 Setting Oracle system tables in a DATA step is another way to extract information from these tables. The SAS counterpart of the Oracle system tables are the dictionary tables in the SASHELP library. However, extracting information from the SAS dictionary table into a data set can only be accomplished using Proc SQL. To avoid confusion as to how to retrieve information from the various metadata sources, my suggestion is to avoid using a DATA step. 2 NESUG 17 Posters It is important to know which columns in the database are indexed because including these variables in the WHERE clause of SQL queries can substantially reduce the time it takes for queries to finish executing. Are the Indices Being Used? A common problem that both the users of a database and a reader of a textbook face is whether or not to use an index. Let us suppose a SAS user wanted to find out information on ‘procs’ in the Procedures manual. After looking up the word in the index the user might find that the word ‘proc’ appears on 95% of the pages in the manual. The user could consult the index to find where the first page the word ‘proc’ occurs, check that page for the information of interest, consulting the index again if necessary, checking that page and so forth. Alternatively, the user could start from page 1 and read every page until she finds the information of interest. As it turns out, the decision to use an index when querying a database is not totally left up to the user. When an SQL statement is submitted, the information in the code is passed along to the query optimizer, which determines the best possible execution plan to return the records you requested. The Oracle query optimizer uses a cost-based approach to make its decision based upon statistics gathered about the tables and indices. The SAS user has the opportunity to inspect the query execution plan, but must first define the table that the execution plan information will populate by submitting the following code: proc sql; connect to oracle (user=&me password=&myob path=&lesstaken); execute( create table Plan_Table ( statement_id varchar2(30), timestamp date, remarks varchar2(80), operation varchar2(30), options varchar2(30), object_node varchar2(128), object_owner varchar2(30), object_name varchar2(30), object_instance number(38), object_type varchar2(30), optimizer varchar2(255), search_columns number, id number(38), parent_id number(38), position number(38), cost number(38), cardinality number(38), bytes number(38), other_tag varchar2(255), partition_start varchar2(255), partition_stop varchar(255), partition_id number(38), other long, distribution varchar2(30) ) ) by oracle; 3 NESUG 17 Posters By default, the table Plan_Table is where the information regarding the query plan will be outputted. However, any table with the same defining characteristics as Plan_Table is a candidate to be filled with the query plan information, if instructed to do so. Another table with same table definition as Plan_Table can be created by submitting the following piece of code: execute( create table <new table> like Plan_Table) by oracle; The section of code below now requests that the query plan information be outputted into an Oracle table: execute( explain plan <into <new table> > for enter SQL code here3 ) by oracle; disconnect from oracle; quit; Requested information regarding the query execution plan does not overwrite any pre- existing information in the designated table, but appends the new information to it. To delete the records from an existing table for re-use the following code should be submitted: execute( delete * from <table name> ) by oracle; The query plan table has the potential to contain a lot of information, but the discussion here will focus solely on index usage. To ascertain which indices (if any) are used to retrieve the query, the variables operation, object_name and operations from the execution plan table should be consulted. The field operation identifies what operation is performed at that step of the query execution, where the user would be looking for the entry ‘INDEX’. The field object_name will identify the index used. The field operations identifies whether a range scan or a unique scan was used to retrieve the records from the indexed column(s). The SAS counterpart to Oracle’s query execution plan functionality is the _tree option in Proc SQL4. Unfortunately, through SAS Version 8.2 the _tree option does not provide as nearly as much information on the query execution plan as Oracle and no information on index use. For this reason, using the explain plan statement in tandem with the SQL Pass-Through facility is essential to the SAS user for fine-tuning queries against an Oracle database. 3 Omit the CREATE statement and start with SELECT statement. 4 The option _tree is a more detailed and graphical description of the _method option. Lavery (2004) provides one of the first detailed descriptions of _tree. 4 NESUG 17 Posters Though a variable which is indexed is included in the WHERE clause of a query, it is not guaranteed that the index will be used to execute the query. Generally speaking, if the amount of information requested in the WHERE clause of an indexed variable exceeds 30% of the total amount of data for that variable then the index will not be used. Returning to the scenario where a SAS user wanted to obtain information on ‘procs’ from the Procedures manual, she certainly would certainly find it more efficient to start reading the book from the beginning rather than using the index.. Also, using a wildcard at the beginning of a logical expression involving an indexed variable in the WHERE clause will preclude the index from being used.
Load more

Recommended publications
  • Sqlserver 2005, 2008, 2012
    Installation and Startup Guide Edition March 2020 Copyright © Atos IT Solutions and Services GmbH 2020 Microsoft, MS, MS-DOS and Windows are trademarks of Microsoft Corporation. The reproduction, transmission, translation or exploitation of this document or its content is not permitted without express written authority. Offenders will be liable for damages. All rights reserved, including rights created by patent grant or registration of a utility model or design. Right of technical modification reserved. Installation Guide TEMPPO V6.3 Edition March 2020 Contents Contents 1 Introduction ....................................................................................... 1 2 Installation ........................................................................................ 2 3 Startup & first steps ......................................................................... 27 4 Appendix .......................................................................................... 30 Installation Guide TEMPPO V6.3 Edition March 2020 Introduction 1 Introduction This manual describes the installation of TEMPPO (Test Execution, Management, Planning and rePorting Organizer) Version 6.3 as client. Managing the test process involves a large number of engineering disciplines like project management, risk management, high and low level design, development and metrics collection. In former times testers managed their tests and test management with Word table or Excel sheets which had the main disadvantages that tests were not organized, couldn’t be
    [Show full text]
  • Parallel and Append Hint in Insert Statement
    Parallel And Append Hint In Insert Statement Sunrise Gay subjoins his viridescence focalise pryingly. Is Odysseus preconscious when Marlin precool signally? Ocean-going Cole ensanguining unworthily. Insert statement with array inserts, then create an access method that parallel and hint in insert statement We can see which each source i was inserted into excel table only. Parallel statements that appends will append hint will propose an answer for a different sessions can. The table specified in tablespec is the probe table of the hash join. Oracle hint was an error logging table or merge statement itself is not possible. Before you can execute DML statements in parallel, you must display the parallel DML feature. The insert or insert and parallel hint in append hint is that page helpful in. Instructs the optimizer selectivity and parallel insert on the source records mark or azure storage requirements. Oracle choose among different options or may be i missed to understand. You do part of these large, update as cpus is genetated for pointing this hint and parallel in insert statement, the index partition, consider adding an error message is that your help us the. Doing all modifications to statement and parallel hint in append insert statement are too large database table were responsible for the plans and for the definition query? When a mortgage is overloaded and all input DOP is larger than the default DOP, the algorithm uses the default degree of input. Instructs the optimizer to use but full outer court, which prohibit a native execution method based on a hash join.
    [Show full text]
  • The Use of Hints in Object-Relational Query Optimization
    Comput Syst Sci & Eng (2004) 6: 337–345 International Journal of © 2004 CRL Publishing Ltd Computer Systems Science & Engineering The use of hints in object-relational query optimization David Taniar*, Hui Yee Khaw*. Haorianto Cokrowijoyo Tijoe* and Johanna Wenny Rahayu† *School of Business Systems, Monash University, Clayton, Victoria 3800, Australia. Email: {David.Taniar,Haorianto.Tjioe}@infotech.monash.edu.au †Department of Computer Science and Computer Engineering, La Trobe University, Bundoora, Victoria 3803, Australia Email: [email protected] Object-Relational queries are queries which can handle data objects feature on the existing relational data environment. REF is one of most impor- tant data structures in Object-Relational Databases can be explained as a logical pointer to define the link between two tables which similar func- tion to pointers in object oriented programming language. There are three ways of writing REF join queries which are: REF Join, Path Expression Join and DEREF/VALUE Join. In this paper, we study optimization technique for Object-Relational queries using hints. Hints are additional comments which are inserted into an SQL statement for the purpose of instructing or suggesting the optimizer to perform the specified operations. We utilize various hints including Optimizer hints, Table join and anti-join hints, and Access method hints. We analyse performance of various object-relation- al queries particularly in three ways of writing REF queries using the TRACE and TKPROF utilities which provide query execution statistics and exe- cution plans. Keywords: object-relational query optimization, ORBMS, REF 1. INTRODUCTION pointer to define the link between two tables (Taniar, Rahayu and Srivastava, 2003).
    [Show full text]
  • Mysql 5.7: Performance Improvements in Optimizer
    MySQL 5.7: Performance Improvements in Optimizer Olav Sandstå Senior Principal Engineer MySQL Optimizer Team, Oracle April 25, 2016 Copyright © 2016, Oracle and/or its affiliates. All rights reserved. Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 2 Program Agenda 1 Improvements in optimizer • Cost model • New optimizations 2 Understanding query performance • Explain extensions • Optimizer trace 3 Tools for improving query plans • New hints • Query rewrite plugin Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 3 MySQL Optimizer MySQL Server SELECT a, b Cost based JOIN FROM t1 optimizations JOIN t2 Table JOIN ON t1.a = t2.b Cost Model scan JOIN t3 Range Ref t1 ON t2.b = t3.c Parser scan access Optimizer Heuristics WHERE t2.d > 20 AND t2.d < 30; t2 t3 Table/index info Statistics (data dictionary) (storage engines) Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 4 Optimizer Performance Improvements in MySQL 5.7 Cost model improvements: New optimizations: • Cost model for WHERE conditions • Merging of derived tables (condition filtering effect) • Optimization of IN queries – Improved JOIN order • Union ALL optimization • Improved index statistics – Better index selection, better join order • Configurable “cost constants” Copyright © 2016, Oracle and/or its affiliates.
    [Show full text]
  • Workbench-En.Pdf
    MySQL Workbench Abstract This is the MySQL Workbench Reference Manual. It documents the MySQL Workbench Community and MySQL Workbench Commercial releases for versions 8.0 through 8.0.26. If you have not yet installed the MySQL Workbench Community release, please download your free copy from the download site. The MySQL Workbench Community release is available for Microsoft Windows, macOS, and Linux. MySQL Workbench platform support evolves over time. For the latest platform support information, see https:// www.mysql.com/support/supportedplatforms/workbench.html. For notes detailing the changes in each release, see the MySQL Workbench Release Notes. For legal information, including licensing information, see the Preface and Legal Notices. For help with using MySQL, please visit the MySQL Forums, where you can discuss your issues with other MySQL users. Document generated on: 2021-10-01 (revision: 70942) Table of Contents Preface and Legal Notices ................................................................................................................ vii 1 General Information ......................................................................................................................... 1 1.1 What Is New in MySQL Workbench ...................................................................................... 1 1.1.1 New in MySQL Workbench 8.0 Release Series ........................................................... 1 1.1.2 New in MySQL Workbench 6.0 Release Series ..........................................................
    [Show full text]
  • SQL Server Execution Plans Second Edition by Grant Fritchey SQL Server Execution Plans
    SQL Handbooks SQL Server Execution Plans Second Edition By Grant Fritchey SQL Server Execution Plans Second Edition By Grant Fritchey Published by Simple Talk Publishing September 2012 First Edition 2008 Copyright Grant Fritchey 2012 ISBN: 978-1-906434-92-2 The right of Grant Fritchey to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988 All rights reserved. No part of this publication may be reproduced, stored or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording or otherwise) without the prior written consent of the publisher. Any person who does any unauthorized act in relation to this publication may be liable to criminal prosecution and civil claims for damages. This book is sold subject to the condition that it shall not, by way of trade or otherwise, be lent, re-sold, hired out, or otherwise circulated without the publisher's prior consent in any form other than which it is published and without a similar condition including this condition being imposed on the subsequent publisher. Technical Reviewer: Brad McGehee Editors: Tony Davis and Brad McGehee Cover Image by Andy Martin Typeset by Peter Woodhouse & Gower Associates Table of Contents Introduction 13 Changes in This ___________________________________________ Second Edition 15 _________________________________________ Code Examples 16 _______________________________________________________ Chapter 1: Execution Plan Basics
    [Show full text]
  • The Query Optimizer in Oracle Database 19C What's New?
    The Query Optimizer in Oracle Database 19c What’s New? Christian Antognini @ChrisAntognini antognini.ch Christian Antognini • Senior principal consultant and partner at Trivadis • Focus: get the most out of database engines • Logical and physical database design • Query optimizer • Application performance management • Author of Troubleshooting Oracle Performance @ChrisAntognini antognini.ch Agenda • All Environments • Reporting on Hint Usage • Execution Plan Comparison Refer to the Oracle • Online Statistics Gathering Enhancements Database SQL Tuning Guide • Enterprise Edition with Management Packs for technical information • Statistics Maintenance Enhancements about the new features • Real-Time SQL Monitoring for Developers • Enterprise Edition on Exadata The Database Licensing • Automatic Resolution of Plan Regressions Information User Manual • High-Frequency SPM Evolve Advisor Task provides information about • Real-Time Statistics their availability • High-Frequency Automatic Statistics Collection • Quarantine for Runaway SQL Statements • Automatic Indexing Disclaimer • This presentation covers the versions 19.[3-5] • This presentation does not cover the query optimizer features that are specific to the Autonomous Database services All Environments Reporting on Hint Usage • It is an issue to verify whether hints added to SQL statements are actually used • To make it easier, there is a new section in the output generated by the DBMS_XPLAN.DISPLAY* functions • The new section (Hint Report) reports hints into two categories • Valid (used)
    [Show full text]
  • SAP HANA Performance Guide for Developers Company
    PUBLIC SAP HANA Platform 2.0 SPS 04 Document Version: 1.1 – 2019-10-31 SAP HANA Performance Guide for Developers company. All rights reserved. All rights company. affiliate THE BEST RUN 2019 SAP SE or an SAP SE or an SAP SAP 2019 © Content 1 SAP HANA Performance Guide for Developers......................................6 2 Disclaimer................................................................. 7 3 Schema Design..............................................................8 3.1 Choosing the Appropriate Table Type...............................................8 3.2 Creating Indexes..............................................................9 Primary Key Indexes........................................................10 Secondary Indexes.........................................................11 Multi-Column Index Types....................................................12 Costs Associated with Indexes.................................................13 When to Create Indexes..................................................... 14 3.3 Partitioning Tables............................................................15 3.4 Query Processing Examples.....................................................16 3.5 Delta Tables and Main Tables....................................................18 3.6 Denormalization.............................................................19 3.7 Additional Recommendations....................................................21 4 Query Execution Engine Overview...............................................22 4.1
    [Show full text]
  • Postgresql User's Guide
    PostgreSQL User's Guide The PostgreSQL Development Team Edited by Thomas Lockhart PostgreSQL User's Guide by The PostgreSQL Development Team Edited by Thomas Lockhart PostgreSQL is Copyright © 1996-2000 by PostgreSQL Inc. Table of Contents Table of Contents . i List of Tables . xiv List of Examples . xvi Summary. i Chapter 1. Introduction. 1 What is Postgres? . 1 A Short History of Postgres . 1 The Berkeley Postgres Project . 2 Postgres95. 2 PostgreSQL . 3 About This Release . 4 Resources. 4 Terminology . 5 Notation . 6 Problem Reporting Guidelines . 6 Identifying Bugs. 6 What to report . 7 Where to report bugs . 9 Y2K Statement . 9 Copyrights and Trademarks . 10 Chapter 2. SQL Syntax . 11 Key Words. 11 Reserved Key Words. 11 Non-reserved Keywords . 14 Comments . 15 Names. 16 Constants . 16 String Constants . 16 Integer Constants. 17 Floating Point Constants. 17 Constants of Postgres User-Defined Types . 17 Array constants . 18 Fields and Columns . 18 Fields. 18 Columns . 19 Operators. 19 Expressions . 19 Parameters . 20 Functional Expressions . 20 Aggregate Expressions . 20 Target List . 21 Qualification. 21 From List . 21 Chapter 3. Data Types . 23 Numeric Types . 25 The Serial Type . 26 Monetary Type . 26 Character Types . 27 Date/Time Types . 28 i Date/Time Input . 28 Date/Time Output . 33 Time Zones. 34 Internals . 34 Boolean Type. 35 Geometric Types . 35 Point . 36 Line Segment . 36 Box . 36 Path. 37 Polygon . 37 Circle . 38 IP Version 4 Networks and Host Addresses . 38 CIDR. 39 inet . 39 Chapter 4. Operators . ..
    [Show full text]
  • Infor Enterprise Server Technical Reference Guide for Oracle Database Driver Copyright © 2015 Infor
    Infor Enterprise Server Technical Reference Guide for Oracle Database Driver Copyright © 2015 Infor Important Notices The material contained in this publication (including any supplementary information) constitutes and contains confidential and proprietary information of Infor. By gaining access to the attached, you acknowledge and agree that the material (including any modification, translation or adaptation of the material) and all copyright, trade secrets and all other right, title and interest therein, are the sole property of Infor and that you shall not gain right, title or interest in the material (including any modification, translation or adaptation of the material) by virtue of your review thereof other than the non-exclusive right to use the material solely in connection with and the furtherance of your license and use of software made available to your company from Infor pursuant to a separate agreement, the terms of which separate agreement shall govern your use of this material and all supplemental related materials ("Purpose"). In addition, by accessing the enclosed material, you acknowledge and agree that you are required to maintain such material in strict confidence and that your use of such material is limited to the Purpose described above. Although Infor has taken due care to ensure that the material included in this publication is accurate and complete, Infor cannot warrant that the information contained in this publication is complete, does not contain typographical or other errors, or will meet your specific requirements. As such, Infor does not assume and hereby disclaims all liability, consequential or otherwise, for any loss or damage to any person or entity which is caused by or relates to errors or omissions in this publication (including any supplementary information), whether such errors or omissions result from negligence, accident or any other cause.
    [Show full text]
  • The Use of Hints in Sql-Nested Query Optimization
    Journal of Data Mining and Knowledge Discovery ISSN: 2229–6662 & ISSN: 2229–6670, Volume 3, Issue 1, 2012, pp.-54-57. Available online at http://www. bioinfo. in/contents. php?id=42 THE USE OF HINTS IN SQL-NESTED QUERY OPTIMIZATION LOKHANDE A.D. AND SHETE R.M. M. E Computer Science and Engineering Dept., Sipna C. O. E. T. Amravati, MS, India. *Corresponding Author: Email- [email protected] and [email protected] Received: February 21, 2012; Accepted: March 15, 2012 Abstract- The query optimization phase in query processing plays a crucial role in choosing the most efficient strategy for executing a que- ry. In this paper, we study an optimization technique for SQL-Nested queries using Hints. Hints are additional comments that are inserted into an SQL statement for the purpose of instructing the optimizer to perform the specified operations. We utilize various Hints including Optimizer Hints, Table join and anti-join Hints, and Access method Hints. We analyse the performance of various nested queries using the TRACE and TKPROF utilities which provide query execution statistics and execution plan. Keywords- Hint, query optimization, parsing. Citation: Lokhande A.D. and Shete R.M. (2012) The use of Hints in SQL-Nested query optimization. Journal of Data Mining and Knowledge Discovery, ISSN: 2229–6662 & ISSN: 2229–6670, Volume 3, Issue 1, pp.-54-57. Copyright: Copyright©2012 Lokhande A.D. and Shete R.M. This is an open-access article distributed under the terms of the Creative Com- mons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.
    [Show full text]
  • Bao: Learning to Steer Query Optimizers
    Bao: Learning to Steer Query Optimizers Ryan Marcus12, Parimarjan Negi1, Hongzi Mao1, Nesime Tatbul12, Mohammad Alizadeh1, Tim Kraska1 1MIT CSAIL 2Intel Labs fryanmarcus, pnegi, hongzi, tatbul, alizadeh, [email protected] ABSTRACT 60.2s PostgreSQL Query optimization remains one of the most challenging 60 PostgreSQL (no loop join) problems in data management systems. Recent efforts to apply machine learning techniques to query optimization 40 challenges have been promising, but have shown few prac- tical gains due to substantive training overhead, inability 21.2s to adapt to changes, and poor tail performance. Motivated 20 19.7s by these difficulties and drawing upon a long history of re- search in multi-armed bandits, we introduce Bao (the Bandit 0.4s optimizer). Bao takes advantage of the wisdom built into Query latency (seconds) 0 existing query optimizers by providing per-query optimiza- 16b 24b tion hints. Bao combines modern tree convolutional neu- JOB Query ral networks with Thompson sampling, a decades-old and well-studied reinforcement learning algorithm. As a result, Figure 1: Disabling the loop join operator in PostgreSQL Bao automatically learns from its mistakes and adapts to can improve (16b) or harm (24b) a particular query's per- changes in query workloads, data, and schema. Experimen- formance. These example queries are from the Join Order tally, we demonstrate that Bao can quickly (an order of mag- Benchmark (JOB) [30]. nitude faster than previous approaches) learn strategies that improve end-to-end query execution performance, including tail latency. In cloud environments, we show that Bao can 2. Brittleness. While performing expensive training oper- offer both reduced costs and better performance compared ations once may already be impractical, changes in query with a sophisticated commercial system.
    [Show full text]