Query Execution and Optimization Query Execution: Parameters ...

Query Execution and Optimization

Query Execution: Parameters

Query Execution: Example

Design parameters for physical schema:

 Number of tuples in relations: 3 Mio Tapes

 Hardware type and structure

1 Mio Movies

 Data volume: # pages for relations  Typical operations: types of queries  Indexes to the data - Index types - Index implementation and organization - Index utilization 10.2

FU-Berlin, DBS I 2006, Hinze / Scholz

FU-Berlin, DBS I 2006, Hinze / Scholz

Execution plans Logical optimization Physical Optimization

CREATE TABLE Movie ( id INTEGER, title VARCHAR(60), category CHAR(10), year DATE, director VARCHAR(30), pricePDay DECIMAL(4,2), length INTEGER, … );

CREATE TABLE Tape( id INTEGER, format CHAR(5), movie_id INTEGER, …); 500000 Rents CREATE TABLE Rental( tape_id INTEGER, mem_no INTEGER, from_date DATE, until_date DATE, …); 10.3

Query Execution: Example

Query Execution: Example

Query Execution: Example

 Data volume

 Typical data update rates

 Typical operations

 Movie:

 Browse or query the movie table

- pages à 4KB, PCTFREE = 30% , ~2800Bytes usage

 Movie:

- Low update frequency, high read load, - Medium growth

- ~ 120B / row, 1 Mill tuples, ~120 MB - 23 records per page, 43,479 pages

- Very high frequency

 Rent a tape:

 Tape

 Tape:

- access Customer (by name or id), access Tape (by tape-id), - Insert into Rental table - High frequency (10 / minute ?)

- Low update frequency, high read load, - Medium growth

- ~ 20 B / row, 3 Mill tuples, ~ 60 MB - 143 records per page, 20,980 pages

10.4

 Rental - High update frequency, - High growth rate 10.5

FU-Berlin, DBS I 2006, Hinze / Scholz

- ~ 20 B / row, 500,000 tuples, ~10 MB - 143 records per page, 4,597 pages

FU-Berlin, DBS I 2006, Hinze / Scholz

FU-Berlin, DBS I 2006, Hinze / Scholz

 Rents:

 Return a tape: - Access rentals, access Movie table to calculate the price - update Rentals - High frequency

10.6

1

Query Execution: Structure

Query Execution: Principles

Query Execution: Execution plan example

 Query execution sequence:

 Set-oriented query logic compiled onto record interface of DBS  Record interface defined by set of operators  Important operators:

 Structures: Index on Movie(category)

 Main difference to language compilers: translation is data dependent 10.7

 Query:

Single row table access Table scan: reads a table sequentially Index scan: reads index tree leaves sequentially from x = key value Join operator for two streams of rows (records) Filter operators Projection

SELECT title FROM Movie WHERE category = 'SciFi' AND pricePDay < 3.00;

 Execution plan

 Order of execution defined by execution plan 10.8

FU-Berlin, DBS I 2006, Hinze / Scholz

User-defined query Parsing Query validation View resolution Query optimization Execution plan creation Code creation Execution Query result

FU-Berlin, DBS I 2006, Hinze / Scholz

FU-Berlin, DBS I 2006, Hinze / Scholz

1. 2. 3. 4. 5. 6. 7. 8. 9.

- Index access: take rowIds x from index one after the other for keyVal = ‘SciFi' - Table access: for each x fetch the tuple - Filter: if it passes the filter pricePDay < 3 - Projection: project on title

10.9

Query Execution: Execution plan

Query Execution: Execution plan

Query Execution: Oracle explain usage

 Often represented as tree  Nodes building blocks of operations to

 Oracle: EXPLAIN command

 Oracle:

- creates a table with information about query plan

- access data (scan of base table or index) and / or - transform data (project, sort, join, ...)

 Example:

Filter (pricePD < 2) Table_access (rowID) Index Scan (idx_m_category, ‚SciFi')

Data transformation 10.10

Query Query Plan Plan ----------------------------------------------------------------------------------SELECT Cost SELECT STATEMENT STATEMENT Cost == TABLE TABLE ACCESS ACCESS BY BY INDEX INDEX ROWID ROWID MOVIE MOVIE INDEX INDEX RANGE RANGE SCAN SCAN MOVIE_CATEGORY_INDEX MOVIE_CATEGORY_INDEX 10.11

FU-Berlin, DBS I 2006, Hinze / Scholz

Data access

CREATE INDEX movie_category_index ON movie(category); SELECT title FROM Movie WHERE category = 'SciFi' AND pricePDay < 3.00;

Project (title)

FU-Berlin, DBS I 2006, Hinze / Scholz

FU-Berlin, DBS I 2006, Hinze / Scholz

SELECT title FROM Movie WHERE category = 'SciFi' AND pricePDay < 3.00;

 Example:

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 NUMERIC,  Plan_table object_type VARCHAR2(30), Stores explain results optimizer VARCHAR2(255), Created once search_columns NUMERIC, id NUMERIC, parent_id NUMERIC, position NUMERIC, cost NUMERIC, cardinality NUMERIC, bytes NUMERIC, other_tag VARCHAR2(255), 10.12 other LONG);

- Create plan_table - Explain query - Query plan_table

2

Query Execution: Oracle explain usage

Query Execution: Optimization Example

 Example:

 Query:

- Explain query:

EXPLAIN PLAN SET STATEMENT_ID = 'te1' FOR SELECT title FROM Movie WHERE category = 'SciFi' AND pricePDay < 3.00;

Query Execution: Optimization

Select t.id, m.title, r.mem_no From movie m, rental r, tape t Where t.id=r.tape_id And t.movie_id=m.id;

(Πtape.id, title, mem_no(rental

tape_id=id

tape

movie_id=movie.id

 High level (logical) optimization -

movie)

dictionary independent (algebraic, "logical") transformation of the query according to the algebraic laws of relational algebra

 Why optimization?  Variant 0: Join(Join(movie, rental), tape): creates 1 Mill * 500000 tuples (cross product), then deletes unwanted tuples

Query plan_table:

 Variant 1: Join(Join(movie, tape), rental): creates 1 Mill * x tuples, then deletes unnecessary tuples  Variant 2: Join(Join(rental, tape), movie): only rented tapes, only movies to rented tapes 10.14

 Low level (physical) optimization FU-Berlin, DBS I 2006, Hinze / Scholz

10.13

FU-Berlin, DBS I 2006, Hinze / Scholz

FU-Berlin, DBS I 2006, Hinze / Scholz

SELECT LPAD(' ',2*(LEVEL-1))||operation||' '||options ||' '||object_name ||' '|| DECODE(id, 0, 'Cost = '||position) "Query Plan" FROM plan_table START WITH id = 0 AND statement_id = 'te1' CONNECT BY PRIOR id = parent_id AND statement_id ='te1';

physical level using indexes ("internal") cost based selection of optimal plan using database statistics

10.15

Query Execution: Logical Optimization

Query Execution: Logical Optimization

Query Execution: Logical Optimization

 Normalizes statements:

 Normalizes statements:

 Heuristic for logical optimization

- Eliminate ANY / ALL operators SELECT … WHERE val

- other ‘additional’ constructs (BETWEEN) - Evaluate expressions as far as possible

> ANY (x, y);

⇒ val > x OR val > y

SELECT … WHERE x > 0.5 * z/100 * 4 ⇒

SELECT … WHERE x > ALL(SELECT y FROM R WHERE z=10);

x > z/200

 Focus on applying algebraic transformation rules - Commutative selection and join - Distributive selection, projection - …

10.17

FU-Berlin, DBS I 2006, Hinze / Scholz

10.16

FU-Berlin, DBS I 2006, Hinze / Scholz

FU-Berlin, DBS I 2006, Hinze / Scholz

⇒ NOT ( x