M.Kersten 2008 1 MonetDB, Cracking and recycling Martin Kersten CWI Amsterdam.

Slides:



Advertisements
Similar presentations
C-Store: Self-Organizing Tuple Reconstruction Jianlin Feng School of Software SUN YAT-SEN UNIVERSITY Apr. 17, 2009.
Advertisements

Lecture 13: Query Execution. Where are we? File organizations: sorted, hashed, heaps. Indexes: hash index, B+-tree Indexes can be clustered or not. Data.
B+-trees. Model of Computation Data stored on disk(s) Minimum transfer unit: a page = b bytes or B records (or block) N records -> N/B = n pages I/O complexity:
Query Evaluation. An SQL query and its RA equiv. Employees (sin INT, ename VARCHAR(20), rating INT, age REAL) Maintenances (sin INT, planeId INT, day.
B+-tree and Hashing.
1 Overview of Storage and Indexing Chapter 8 (part 1)
Query Optimization 3 Cost Estimation R&G, Chapters 12, 13, 14 Lecture 15.
MonetDB/SQL Meets SkyServer: the Challenges of a Scientific Database Milena Ivanova, Niels Nes, Romulo Goncalves, Martin Kersten CWI, Amsterdam Presented.
Dutch-Belgium DataBase Day University of Antwerp, MonetDB/x100 Peter Boncz, Marcin Zukowski, Niels Nes.
1 Overview of Storage and Indexing Chapter 8 1. Basics about file management 2. Introduction to indexing 3. First glimpse at indices and workloads.
Basics of Operating Systems March 4, 2001 Adapted from Operating Systems Lecture Notes, Copyright 1997 Martin C. Rinard.
Layers of a DBMS Query optimization Execution engine Files and access methods Buffer management Disk space management Query Processor Query execution plan.
Query Processing Presented by Aung S. Win.
Relational Database Performance CSCI 6442 Copyright 2013, David C. Roberts, all rights reserved.
Cloud Computing Lecture Column Store – alternative organization for big relational data.
Modularizing B+-trees: Three-Level B+-trees Work Fine Shigero Sasaki* and Takuya Araki NEC Corporation * currently with 1st Nexpire Inc.
Index tuning Performance Tuning.
Database Systems Design, Implementation, and Management Coronel | Morris 11e ©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Database Performance Tuning and Query Optimization.
1 Physical Data Organization and Indexing Lecture 14.
ICOM 6005 – Database Management Systems Design Dr. Manuel Rodríguez-Martínez Electrical and Computer Engineering Department Lecture 14 – Join Processing.
Context Tailoring the DBMS –To support particular applications Beyond alphanumerical data Beyond retrieve + process –To support particular hardware New.
Physical Database Design & Performance. Optimizing for Query Performance For DBs with high retrieval traffic as compared to maintenance traffic, optimizing.
Physical Database Design Chapter 6. Physical Design and implementation 1.Translate global logical data model for target DBMS  1.1Design base relations.
EN : Adv. Storage and TP Systems Cost-Based Query Optimization.
Database Tuning Prerequisite Cluster Index B+Tree Indexing Hash Indexing ISAM (indexed Sequential access)
Master Thesis Defense Jan Fiedler 04/17/98
MonetDB/X100 hyper-pipelining query execution Peter Boncz, Marcin Zukowski, Niels Nes.
Ashwani Roy Understanding Graphical Execution Plans Level 200.
« Performance of Compressed Inverted List Caching in Search Engines » Proceedings of the International World Wide Web Conference Commitee, Beijing 2008)
Chapter 13 Query Processing Melissa Jamili CS 157B November 11, 2004.
M.Kersten MonetDB, a Column-Store in Midflight Martin Kersten CWI Amsterdam.
Physical Database Design I, Ch. Eick 1 Physical Database Design I About 25% of Chapter 20 Simple queries:= no joins, no complex aggregate functions Focus.
C-Store: How Different are Column-Stores and Row-Stores? Jianlin Feng School of Software SUN YAT-SEN UNIVERSITY May. 8, 2009.
M.Kersten Dec 31, Cracking the database store The far side of the Moon Martin Kersten, Stefan Manegold Centre for Mathematics and Computer Science.
M.Kersten The MonetDB Architecture Martin Kersten CWI Amsterdam.
1 Overview of Storage and Indexing Chapter 8 (part 1)
Database Systems Design, Implementation, and Management Coronel | Morris 11e ©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Overview of Storage and Indexing Chapter 8.
1 Overview of Storage and Indexing Chapter 8. 2 Data on External Storage  Disks: Can retrieve random page at fixed cost  But reading several consecutive.
1 Biometric Databases. 2 Overview Problems associated with Biometric databases Some practical solutions Some existing DBMS.
1 Virtual Machine Memory Access Tracing With Hypervisor Exclusive Cache USENIX ‘07 Pin Lu & Kai Shen Department of Computer Science University of Rochester.
Distributed Query Processing. Agenda Recap of query optimization Transformation rules for P&D systems Memoization Queries in heterogeneous systems Query.
Buffer-pool aware Query Optimization Ravishankar Ramamurthy David DeWitt University of Wisconsin, Madison.
Physical Database Design Purpose- translate the logical description of data into the technical specifications for storing and retrieving data Goal - create.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 B+-Tree Index Chapter 10 Modified by Donghui Zhang Nov 9, 2005.
CS 540 Database Management Systems
DMBS Internals I February 24 th, What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the.
1 Overview of Query Evaluation Chapter Outline  Query Optimization Overview  Algorithm for Relational Operations.
Database Systems, 8 th Edition SQL Performance Tuning Evaluated from client perspective –Most current relational DBMSs perform automatic query optimization.
Execution Plans Detail From Zero to Hero İsmail Adar.
Diving into Query Execution Plans ED POLLACK AUTOTASK CORPORATION DATABASE OPTIMIZATION ENGINEER.
Oracle Announced New In- Memory Database G1 Emre Eftelioglu, Fen Liu [09/27/13] 1 [1]
Database cracking Stratos Idreos, Martin Kersten and Stefan Manegold
CS 540 Database Management Systems
Tree-Structured Indexes
CSC 4250 Computer Architectures
Indices in a DBMS.
Database Performance Tuning and Query Optimization
Introduction to Query Optimization
JULIE McLAIN-HARPER LINKEDIN: JM HARPER
B+-Trees and Static Hashing
Selected Topics: External Sorting, Join Algorithms, …
B+Trees The slides for this text are organized into chapters. This lecture covers Chapter 9. Chapter 1: Introduction to Database Systems Chapter 2: The.
Implementation of Relational Operations
Chapter 11 Database Performance Tuning and Query Optimization
Evaluation of Relational Operations: Other Techniques
Self-organizing Tuple Reconstruction in Column-stores
Database Systems (資料庫系統)
Tree-Structured Indexes
Presentation transcript:

M.Kersten MonetDB, Cracking and recycling Martin Kersten CWI Amsterdam

M.Kersten Try to maximize performance Paste Present Potency Cracking B-tree, Hash Indices Materialized Views

M.Kersten Indices in database systems focus on: All tuples are equally important for fast retrieval There are ample resources to maintain indices MonetDB cracks the database into pieces based on actual query load Find a trusted fortune teller

M.Kersten 2008 Cracking algorithms Physical reorganization happens per column based on selection predicates. Split a piece of a column in two new pieces A<10 A>=10 A<10

M.Kersten 2008 Cracking algorithms Physical reorganization happens per column Split a piece of a column in two new pieces Split a piece of a column in three new pieces A<10 A>=10 A<10 5<A<10 A>=10 5<A<10 A<5

M.Kersten 2008 Cracking example select A>5 and A<10

M.Kersten 2008 Cracking example select A>5 and A<

M.Kersten 2008 Cracking example select A>5 and A< >=10

M.Kersten 2008 Cracking example select A>5 and A< >=10

M.Kersten 2008 Cracking example select A>5 and A< >=10 <=5

M.Kersten 2008 Cracking example select A>5 and A< >=10 <=5

M.Kersten 2008 Cracking example select A>5 and A< >=10 <=5

M.Kersten 2008 Cracking example select A>5 and A< >=10 <=5

M.Kersten 2008 Cracking example select A>5 and A< >=10

M.Kersten 2008 Cracking example select A>5 and A< >=10

M.Kersten 2008 Cracking example select A>5 and A< <=5

M.Kersten 2008 Cracking example select A>5 and A< <=5

M.Kersten 2008 Cracking example select A>5 and A< <=5 >5 and <10

M.Kersten 2008 Cracking example select A>5 and A< <=5 >5 and <10

M.Kersten 2008 Cracking example select A>5 and A< <=5 >5 and <10

M.Kersten 2008 Cracking example select A>5 and A< <=5 >5 and <10

M.Kersten 2008 Cracking example select A>5 and A< >5 and <10

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 15

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A<14

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< <= 5 >= 10 > 5

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< <= 5 >= 10 > 5

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< <= 5 >= 10 > 5

M.Kersten 2008 racking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< <= 5 >= 10 > 5 >3 and <14 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< <= 5 >= 10 > 5 >3 and <14 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< <= 5 >= 10 > 5 >3 and <14 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< <= 5 >= 10 > 5 >3 and <14 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< <= 5 >= 10 > 5 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< > 3 >= 10 > 5 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< > 3 >= 10 > 5 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< > 3 >= 10 > 5 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< > 3 >= 10 > 5 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< > 3 >= 10 > 5 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< > 3 >= 10 > 5 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< > 3 >= 10 > 5 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< > 3 >= 10 > 5 <=3

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< > 3 >= 14 > 5 <=3 >=10

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< > 3 >= 14 > 5 <=3 >=10

M.Kersten 2008 Cracking example select A>5 and A< <= 5 >= 10 > 5 Improve data access for future queries select A>3 and A< >3 >= 14 > 5 <=3 >=10 The more we crack the more we learn

M.Kersten 2008 Design The first time a range query is posed on an attribute A, a cracking DBMS makes a copy of column A, called the cracker column of A A cracker column is continuously physically reorganized based on queries that need to touch attribute such as the result is in a contiguous space For each cracker column, there is a cracker index Cracker Index Cracker Column

M.Kersten 2008 A simple range query Try to avoid useless investments

M.Kersten 2008 TPC-H query 6 Try to avoid useless investments

M.Kersten Cracking is easy in a column store and is part of the critical execution path Cracking works under high volume updates Try to avoid useless investments

M.Kersten 2008 Updates Base columns are updated as normally We need to update the cracker column and the cracker index Efficiently Maintain the self-organization properties Two issues: When How

M.Kersten 2008 When to propagate updates in cracking Follow the workload to maintain self-organization Updates become part of query processing When an update arrives, it is not applied For each cracker column there is a pending insertions column and a pending deletions column Pending updates are applied only when a query needs the specific values

M.Kersten 2008 Updates aware select We extended the cracker select operator to apply the needed updates before cracking The select operator: 1. Search the pending insertions column 2. Search the pending deletions column 3. If Steps 1 or 2 find tuples run an update algorithm 4. Search the cracker index 5. Physically reorganize the cracker column 6. Update the cracker index 7. Return a slice of the cracker column

M.Kersten 2008 Merging Start position: 7 values: >35 Start position: 4 values: >12 Start position: 1 values: >1 Insert a new tuple with value 9 The new tuple belongs to the blue piece 9

M.Kersten 2008 Merging Start position: 8 values: >35 Start position: 5 values: >12 Start position: 1 values: >1 Insert a new tuple with value 9 The new tuple belongs to the blue piece 9 Pieces in the cracker column are ordered Tuples inside a piece are not ordered Shifting is not a viable solution

M.Kersten 2008 Merging by Hopping Start position: 8 values: >35 Start position: 4 values: >12 Start position: 1 values: > Insert a new tuple with value 9 We need to make enough room to fit the new tuples

M.Kersten 2008 Merge Gradually A query merges only the qualifying values, i.e., only the values that it needs for a correct and complete result Average cost increases significantly We avoid the large peaks but... Merge CompletelyMerge Gradually

M.Kersten 2008 The Ripple Touch only the pieces that are relevant for the current query

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: >1 Touch only the pieces that are relevant for the current query

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: >1 Select 7<= A< 15 Touch only the pieces that are relevant for the current query

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: >1 Select 7<= A< Pending insertions Touch only the pieces that are relevant for the current query

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: > Pending insertions Touch only the pieces that are relevant for the current query Select 7<= A< 15

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: > Pending insertions Touch only the pieces that are relevant for the current query Select 7<= A< 15

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: > Pending insertions Touch only the pieces that are relevant for the current query Select 7<= A< 15

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: > Pending insertions Touch only the pieces that are relevant for the current query Avoid shifting down non interesting pieces Select 7<= A< 15

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: > Pending insertions Touch only the pieces that are relevant for the current query Avoid shifting down non interesting pieces Select 7<= A< 15

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: > Pending insertions Touch only the pieces that are relevant for the current query Immediately make room for the new tuples Avoid shifting down non interesting pieces Select 7<= A< 15

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: > Pending insertions Touch only the pieces that are relevant for the current query Immediately make room for the new tuples Avoid shifting down non interesting pieces Select 7<= A< 15

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: > Pending insertions Touch only the pieces that are relevant for the current query Immediately make room for the new tuples Avoid shifting down non interesting pieces Select 7<= A< 15

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 4 values: >22 Start position: 1 values: > Pending insertions 29 Touch only the pieces that are relevant for the current query Immediately make room for the new tuples Avoid shifting down non interesting pieces Select 7<= A< 15

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 5 values: >22 Start position: 1 values: > Pending insertions 29 Touch only the pieces that are relevant for the current query Immediately make room for the new tuples Avoid shifting down non interesting pieces Select 7<= A< 15

M.Kersten 2008 The Ripple Start position: 7 values: >35 Start position: 5 values: >22 Start position: 1 values: > Pending insertions 29 Touch only the pieces that are relevant for the current query Immediately make room for the new tuples Avoid shifting down non interesting pieces Select 7<= A< 15

M.Kersten 2008 The Ripple Maintain high performance through the whole query sequence in a self-organizing way

M.Kersten 2008 The Ripple Maintain high performance through the whole query sequence in a self-organizing way Merge GraduallyMerge Completely Merge Ripple

Recycling intermediates M.Kersten

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 74/20 MonetDB Background Operator-at-a-time execution paradigm Canonical implementation of a column-store Reduced dimensionality Finer granularity Simplified overlap analysis Recycler extension of MonetDB engine

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 75/20 Run-time Support Recycler Optimizer MonetDB Architecture SQL MonetDB Server Tactical Optimizer MonetDB Kernel XQuery MAL Recycle Pool function user.s1_2(A0:date,...):void; X5 := sql.bind("sys","lineitem",...); X10 := algebra.select(X5,A0); X12 := sql.bindIdx("sys","lineitem",...); X15 := algebra.join(X10,X12); X25 := mtime.addmonths(A1,A2);... function user.s1_2(A0:date,...):void; X5 := sql.bind("sys","lineitem",...); X10 := algebra.select(X5,A0); X12 := sql.bindIdx("sys","lineitem",...); X15 := algebra.join(X10,X12); X25 := mtime.addmonths(A1,A2);... Admission & Eviction

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 76/20 Instruction Matching Run time comparison of instruction types argument values NameValueData typeSize X110:bat[:oid,:date] T1“sys”:str T2“orders”:str … X1 := sql.bind("sys","orders","o_orderdate",0); … Y3 := sql.bind("sys","orders","o_orderdate",0); Exact matching

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 77/20 Instruction Subsumption NameValueData typeSize X110:bat[:oid,:int]2000 X3130:bat[:oid,:int]700 X5150:bat[:oid,:int]350 … X3 := algebra.select(X1,10,80); … Y3 := algebra.select(X1,20,45); X5 := algebra.select(X1,20,60); X5

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 78/20 Recycle Pool: a Cache with Lineage algebra.join sql.bind(“C1“) algebra.select sql.bind(“C2“) … sql.bind(“C1“) X1 := algebra.select(X1) X2 := sql.bind(“C2“) X3 := algebra.join(X2,X3) X4 := Q1

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 79/20 Recycle Pool: a Cache with Lineage algebra.join sql.bind(“C1“) algebra.select sql.bind(“C2“) X1 := sql.bind(“C1“) X2 := algebra.select(X1) X3 := sql.bind(“C2“) X4 := algebra.join(X2,X3) algebra.join sql.bind(“C3“) … X1 X2 X3 X4 Q2

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 80/20 Mismatching algebra.join sql.bind(“C1“) algebra.select sql.bind(“C2“) X1 := sql.bind(“C1“) X2 := algebra.select(X1) X3 := sql.bind(“C2“) X4 := algebra.join(X2,X3) algebra.join sql.bind(“C3“) … Y1 Y2 Y3 Y4 Y3 := sql.bind(“C2“) Y2 := algebra.select(Y1) Y1 := sql.bind(“C1“) Y4 := algebra.join(Y2,Y3) !=X2 !=X3 Q2

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 81/20 Admission Policies Decide about storing the results KEEPALL all instructions advised by the optimizer CREDIT instructions supplied with credits storage ‘paid’ with 1 credit reuse returns credits lack of reuse limits admission and resource claims

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 82/20 Cache Policies Decide about eviction of intermediates Filter ‘top’ instructions without dependents Pick instructions with smallest utility LRU : time of computation or last reuse BENEFIT : estimated contribution to performance: CPU and I/O costs, recycling Triggered by resource limitations (memory or entries)

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 83/20 TPC-H Evaluation SF1 Baseline performance Impact of design choices Admission policies Cache policies

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 84/20 CREDIT Admission Impact Reused memoryReused entries Hit ratio to KeepAll

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 85/20 Cache Policies Evaluation 200 TPC-H queries RPTotalReuse Memory4GB42.7% Entries521928%

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 86/20 SkyServer Evaluation 100 GB subset of DR4 100-query batch from January 2008 log 1.5GB intermediates, 99% reuse Join intermediates major contributor to savings

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 87/20 Summary Database architecture augmented with recycling intermediates Significant performance benefits in SkyServer and TPC-H Self-organizing technique Extension to MonetDB transforming materialization overhead into benefit

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 88/20 Future Work Refining and developing admission and cache policies Opportunities by query class recognition Automatic switch to suitable policies Application to pipelined architectures

30/06/2009 SIGMOD'09 Providence, RI An Architecture for Recycling Intermediates M. Ivanova, M. L. Kersten, N. Nes, R. Goncalves 89/20 Recycling Is Green