adaptive query processing

of 66/66
Adaptive Query Processing Adapted from a Tutorial given at SIGMOD 2006 by: Amol Deshpande, University of Maryland Joseph M. Hellerstein, University of California, Berkeley Vijayshankar Raman, IBM Almaden Research Center

Post on 04-Feb-2016

41 views

Category:

Documents

0 download

Embed Size (px)

DESCRIPTION

Adaptive Query Processing. Adapted from a Tutorial given at SIGMOD 2006 by: Amol Deshpande, University of Maryland Joseph M. Hellerstein, University of California, Berkeley Vijayshankar Raman, IBM Almaden Research Center. Data Independence Redux. d app. d env.

TRANSCRIPT

  • Adaptive Query ProcessingAdapted from a Tutorial given at SIGMOD 2006 by:Amol Deshpande, University of MarylandJoseph M. Hellerstein, University of California, BerkeleyVijayshankar Raman, IBM Almaden Research Center

  • Data Independence ReduxThe taproot of modern database technologySeparation of specification (what) from implementation (how)

    Refamiliarizing ourselves: Why do we care about data independence?

  • D. I. AdaptivityQuery Optimization: the key to data independencebridges specification and implementationisolates static applications from dynamic environments

    How does a DBMS account for dynamics in the environment?

    This tutorial is on a 30-year-old topicWith a 21st-Century renaissanceADAPTIVITY

  • Why the Renaissance?Breakdown of traditional query optimizationQueries over many tablesUnreliability of traditional cost estimationSuccess & maturity make problems more apparent, criticalc.f. Oracle v6!

    Query processing in new environmentsE.g. data integration, web services, streams, P2P, sensornets, hosting, etc.Unknown and dynamic characteristics for data and runtimeIncreasingly aggressive sharing of resources and computationInteractivity in query processing

    Note two separate themes? Unknowns: even static properties often unknown in new environmentsand often unknowable a prioriDynamics: can be very high -- motivates intra-query adaptivity?

  • 20th Century SummarySystem Rs optimization scheme deemed the winner for 25 years

    Nearly all 20thC research varied System Rs individual stepsMore efficient measurement (e.g. sampling)More efficient/effective models (samples, histograms, sketches)Expanded plan spaces (new operators, bushy trees, richer queries and data models, materialized views, parallelism, remote data sources, etc)Alternative planning strategies (heuristic and enumerative)

    Speaks to the strength of the schemeindependent innovation on multiple frontsas compared with tight coupling of INGRES

    But minimal focus on the interrelationship of the stepsWhich, as we saw from Ingres, also affects the plan space

  • 21st Century Adaptive Query Processing(well, starts in late 1990s)

    Revisit basic architecture of System RIn effect, change the basic adaptivity loop!

    As you examine schemes, keep an eye on:Rate of change in the environment that is targetedHow radical the scheme is wrt the System R schemeease of evolutionary changeIncrease in plan space: are there new, important opportunities?even if environment is ostensibly static!New overheads introducedHow amenable the scheme is to independent innovation at each stepMeasure/Analyze/Plan/Actuate

  • Tangentially Related WorkAn incomplete list!!!

    Competitive Optimization [Antoshenkov93]Choose multiple plans, run in parallel for a time, let the most promising finish1x feedback: execution doesnt affect planning after the competitionParametric Query Optimization [INSS92, CG94, etc.]Given partial stats in advance. Do some planning and prune the space. At runtime, given the rest of statistics, quickly finish planning.Changes interaction of Measure/Model and PlanningNo feedback whatsoever, so nothing to adapt to!Self-Tuning/Autonomic Optimizers [CR94, CN97, BC02, etc.]Measure query execution (e.g. cardinalities, etc.)Enhances measurement, on its own doesnt change the loopConsider building non-existent physical access paths (e.g. indexes, partitions)In some senses a separate loop adaptive database designLonger timescales

  • Tangentially Related Work IIRobust Query Optimization [CHG02, MRS+04, BC05, etc.]Goals: Pick plans that remain predictable across wide ranges of scenariosPick least expected cost planChanges cost function for planning, not necessarily the loop.If such functions are used in adaptive schemes, less fluctuation [MRS+04]Hence fewer adaptations, less adaptation overhead

    Adaptive query operators [NKT88, KNT89, PCL93a, PCL93b]E.g. memory-adaptive sort and hash-joinDoesnt address whole-query optimization problemsHowever, if used with AQP, can result in complex feedback loopsEspecially if their actions affect each others models!

  • Extended Topics in Adaptive QPAn incomplete list!!

    Parallelism & DistributionRiver [A-D03] FLuX [SHCF03, SHB04]Distributed eddies [TD03]

    Data StreamsAdaptive load sheddingShared query processing

  • Adaptive Selection OrderingTitle slide

  • Selection OrderingComplex predicates on relations commonEg., on an employee relation:((salary > 120000) AND (status = 2)) OR ((salary between 90000 and 120000) AND (age < 30) AND (status = 1)) OR Selection ordering problem Decide the order in which to evaluate the individual predicates against the tuplesWe focus on evaluating conjunctive predicates (containing only ANDs) Example Queryselect * from R where R.a = 10 and R.b < 20 and R.c like %name%;

  • Why Study Selection OrderingMany join queries reduce to this problemQueries posed against a star schemaQueries where only pipelined left-deep plans are consideredQueries involving web indexes

    Increasing interest in recent yearsWeb indexes [CDY95, EHJKMW96, GW00]Web services [SMWM06]Data streams [AH00, BMMNW04]Sensor Networks [DGMH05]

    Similar to many problems in other domainsSequential testing (e.g. for fault detection) [SF01, K01]Learning with attribute costs [KKM05]

  • Execution Strategies

    Pipelined execution (tuple-at-a-time)Static optimization ? 1. Using the KBZ algorithm Order by c/(1-p) Assumes predicate independence 2. A greedy algorithm Known to be 4-approximate

  • Adaptive Greedy [BMMNW04]Context: Pipelined query plans over streaming dataExample:Three independent predicatesOptimal execution plan orders by selectivities (because costs are identical)

  • Adaptive Greedy [BMMNW04]Monitor the selectivitiesSwitch order if the predicates not ordered by selectivitiesRsample Randomly sampleR.a = 10R.b < 20R.c like estimate selectivities of the predicatesover the tuples of the profileReoptimizerIF the current plan not optimal w.r.t. these new selectivitiesTHEN reoptimize using the Profile

  • Adaptive Greedy [BMMNW04]Correlated SelectionsMust monitor conditional selectivities

    ReoptimizerUses conditional selectivities to detect violationsUses the profile to reoptimizeO(n2) selectivities need to be monitored

  • Adaptive Greedy [BMMNW04]Advantages: Can adapt very rapidlyTheoretical guarantees on performanceNot known for any other AQP protocols

    Disadvantages:Limited applicabilityOnly applies to selection ordering and specific types of join queriesPossibly high runtime overheadsSeveral heuristics described in the paper

  • Eddies [AH00]Treat query processing as routing of tuples through operatorsPipelined query execution using an eddyAn eddy operator Intercepts tuples from sources and output tuples from operators Executes query by routing source tuples through operators

  • Eddies [AH00]An R Tuple: r1r1r1

  • Eddies [AH00]An R Tuple: r1r1

  • Eddies [AH00]An R Tuple: r1r1

  • Eddies [AH00]An R Tuple: r1r1

  • Eddies [AH00]An R Tuple: r1r1satisfiedr1r1r1not satisfiededdy looks at the next tupleFor a query with only selections, ready = complement(done)

    abcreadydone1510AnameA101010

  • Eddies [AH00]An R Tuple: r2r2

  • Eddies [AH00]An R Tuple: r2r2if done = 111, send to output r2

  • Eddies [AH00]Adapting order is easyJust change the operators to which tuples are sentCan be done on a per-tuple basisCan be done in the middle of tuples pipelineHow are the routing decisions made ?Using a routing policy

  • Routing Policy 1: Non-adaptiveSimulating a single static orderE.g. operator 1, then operator 2, then operator 3

    Routing policy: if done = 000 route to 1 100 route to 2 110 route to 3

  • Overhead of RoutingPostgreSQL implementation of eddies using bitset lookups [Telegraph Project]Queries with 3 selections, of varying costRouting policy uses a single static order, i.e., no adaptation

    Chart2

    11.2

    11.03

    11.005

    No-eddies

    Eddies

    Selection cost

    Normalized Cost

    Sheet1

    10 sec100 sec

    No-eddies111

    Eddies1.21.031.005

    Sheet1

    No-eddies

    Eddies

    Selection cost

    Normalized Cost

    Sheet2

    Sheet3

  • Routing Policy 2: DeterministicMonitor costs and selectivities continuouslyReoptimize periodically using KBZ

    Statistics Maintained: Costs of operators Selectivities of operators

    Routing policy: Use a single order for a batch of tuples Periodically apply KBZCan use the A-Greedy policy for correlated predicates

  • Overhead of Routing and ReoptimizationAdaptation using batchingReoptimized every X tuples using monitored selectivitiesIdentical selectivities throughout experiment measures only the overhead

    Chart4

    11.171.225.7

    11.007961.022

    11.006491.011.13

    No-eddies

    Eddies - No reoptimization

    Eddies - Batch Size = 100 tuples

    Eddies - Batch Size = 1 tuple

    Selection Cost

    Normalized Cost

    Sheet1

    10 sec100 sec

    10 sec100 secNo-eddies111

    No-eddies111Eddies - No reoptimization1.171.007961.00649

    Eddies1.21.031.005Eddies - Batch Size = 100 tuples1.221.021.01

    Eddies - Batch Size = 1 tuple5.721.13

    Sheet1

    No-eddies

    Eddies

    Selection cost

    Normalized Cost

    Sheet2

    No-eddies

    Eddies - No reoptimization

    Eddies - Batch Size = 100 tuples

    Eddies - Batch Size = 1 tuple

    Selection Cost

    Normalized Cost

    Sheet3

  • Routing Policy 3: Lottery SchedulingOriginally suggested routing policy [AH00]Applicable when each operator runs in a separate threadCan also be done single-threaded, via an event-driven query executorUses two easily obtainable pieces of information for making routing decisions:Busy/idle status of operatorsTickets per operator

  • Routing Policy 3: Lottery SchedulingRouting decisions based on busy/idle status of operatorsRationale: Every thread gets equal time SO IF an operator is busy, THEN its cost is perhaps very high

  • Routing Policy 3: Lottery SchedulingRouting decisions based on ticketsRules: 1. Route a new tuple randomly weighted according to the number of tickets tickets(O1) = 10tickets(O2) = 70tickets(O3) = 20Will be routed to: O1 w.p. 0.1 O2 w.p. 0.7 O3 w.p. 0.2r

  • Routing Policy 3: Lottery SchedulingRouting decisions based on ticketsRules: 1. Route a new tuple randomly weighted according to the number of tickets tickets(O1) = 10tickets(O2) = 70tickets(O3) = 20r

  • Routing Policy 3: Lottery SchedulingRouting decisions based on ticketsRules: 1. Route a new tuple randomly weighted according to the number of tickets 2. route a tuple to an operator Oi tickets(Oi) ++;tickets(O1) = 11tickets(O2) = 70tickets(O3) = 20

  • Routing Policy 3: Lottery SchedulingRouting decisions based on ticketsrRules: 1. Route a new tuple randomly weighted according to the number of tickets 2. route a tuple to an operator Oi tickets(Oi) ++; 3. Oi returns a tuple to eddy tickets(Oi) --;tickets(O1) = 11tickets(O2) = 70tickets(O3) = 20

  • Routing Policy 3: Lottery SchedulingRouting decisions based on ticketsrRules: 1. Route a new tuple randomly weighted according to the number of tickets 2. route a tuple to an operator Oi tickets(Oi) ++; 3. Oi returns a tuple to eddy tickets(Oi) --;tickets(O1) = 10tickets(O2) = 70tickets(O3) = 20

  • Routing Policy 3: Lottery SchedulingRouting decisions based on ticketsRationale: Tickets(Oi) roughly corresponds to (1 - selectivity(Oi)) So more tuples are routed to the more selective operators Rules: 1. Route a new tuple randomly weighted according to the number of tickets 2. route a tuple to an operator Oi tickets(Oi) ++; 3. Oi returns a tuple to eddy tickets(Oi) --;tickets(O1) = 10tickets(O2) = 70tickets(O3) = 20

  • Routing Policy 3: Lottery SchedulingEffect of the combined lottery scheduling policy:Low cost operators get more tuplesHighly selective operators get more tuplesSome tuples are randomly, knowingly routed according to sub-optimal ordersTo exploreNecessary to detect selectivity changes over time

  • Routing Policy 4: Content-based RoutingRouting decisions made based on the values of the attributes [BBDW05]Also called conditional planning in a static setting [DGHM05] Less useful unless the predicates are expensiveAt the least, more expensive than r.d > 100Example Eddy notices: R.d > 100 sel(op1) > sel(op2) & R.d < 100 sel(op1) < sel(op2)

    Routing decisions for new tuple r: IF (r.d > 100): Route to op1 first w.h.p ELSE Route to op2 first w.h.pExpensive predicates

  • Eddies: Post-MortemCost of adaptivityRouting overheadsMinimal with careful engineeringE.g. using bitset-indexed routing arraysBatching helps tremendouslyStatistics MaintenanceExecuting the routing policy logic

  • DiscussionBenefits for AQP techniques come from two placesIncreased explored plan spaceCan use different plans for different parts of data AdaptationCan change the plan according to changing data characteristics

    Selection ordering is STATELESSNo inherent cost of switching plansCan switch the plan without worrying about operator statesKey to the simplicity of the techniques

  • DiscussionAdaptation is not freeCosts of monitoring and maintaining statistics can be very highA selection operation may take only 1 instruction to executeComparable to updating a countSufficient statisticsMay need to maintain only a small set of statistics to detect violations E.g. The O(n2) matrix in Adaptive-Greedy [BBMNW04]

  • Adaptive Join ProcessingTitle slide

  • Outline

    20th Century Adaptivity: Intuition from the Classical Systems

    Adaptive Selection Ordering

    Adaptive Join ProcessingAdditional complexities beyond selection orderingFour plan spacesSimplest: pipelines of Nested Loop JoinsTraditional: Trees of Binary Operators (TOBO)Multi-TOBO: horizontal partitioningDataflows of unary operatorsHandling asynchronyResearch Roundup

  • Select-Project-Join ProcessingQuery: select count(*) from R, S, T where R.a=S.a and S.b=T.b and S.c like %name% and T.d = 10

    An execution plan

    Cost metric: CPU + I/OPlan Space: Traditionally, tree of binary join operators (TOBO):access methodsJoin algorithmsJoin orderAdaptive systems: Some use the same plan space, but switch between plans during executionOthers use much larger plan spacesdifferent adaptation techniques adapt within different plan spaces

  • ApproachPipelined nested-loops plansStatic Rank OrderingDynamic Rank Ordering Eddies, Competition Trees of Binary Join Operators (TOBO)Static: System RDynamic: Switching plans during execution Multiple Trees of Binary Join OperatorsConvergent Query ProcessingEddies with Binary Join OperatorsSTAIRs: Moving state across joinsDataflows of Unary OperatorsN-way joins switching join algorithms during executionAsynchrony in Query Processing

  • Pipelined Nested Loops JoinSimplest method of joining tablesPick a driver table (R). Call the rest driven tablesPick access methods (AMs) on the driven tablesOrder the driven tablesFlow R tuples through the driven tables

    For each r R do: look for matches for r in A; for each match a do: look for matches for in B;

  • Adapting a Pipelined Nested Loops JoinSimplest method of joining tablesPick a driver table (R). Call the rest driven tablesPick access methods (AMs) on the driven tablesOrder the driven tablesFlow R tuples through the driven tables

    For each r R do: look for matches for r in A; for each match a do: look for matches for in B; RKeep this fixed for now

  • Tree Of Binary Join Operators (TOBO) recapStandard plan space considered by most DBMSs todayPick access methods, join order, join algorithmssearch in this plan space done by dynamic programming

    ABRMJNLJNLJDCHJ

  • Switching plans during query executionMonitor cardinalities at well-defined checkpointsIf actual cardinality is too different from estimated,re-optimize to switch to a new plan

    Most widely studied technique:-- Federated systems (InterViso 90, MOOD 96), Red Brick, Query scrambling (96), Mid-query re-optimization (98), Progressive Optimization (04), Proactive Reoptimization (05),

  • QuestionsWhere to place checkpoints ?Typically at materialization pointsWhen to reoptimize ?State reuse a key The cost of switching shouldnt be more than cost of continuingHow to switch ?Try to reuse the work

  • NextEddies

  • Example Databaseselect *from students, enrolled, courseswhere students.name = enrolled.name and enrolled.course = courses.courseStudentsEnrolledCourses

    NameLevelJoeJuniorJenSenior

    NameCourseJoeCS1JenCS2

    CourseInstructorCS2Smith

    NameLevelCourseJoeJuniorCS1JenSeniorCS2

    NameLevelCourseInstructorJenSeniorCS2Smith

  • Symmetric Hash JoinPipelined hash join [WA91]Simultaneously builds and probes hash tables on both sides

    Widely used: adaptive qp, stream joins, online aggregation,

    Nave version degrades to NLJ once memory runs outQuadratic time complexitymemory needed = sum of inputsImproved by XJoins [UF 00]Needs more investigationselect * from students, enrolled where students.name = enrolled.nameStudentsEnrolled

    NameLevelJenSeniorJoeJunior

    NameCourseJoeCS1JenCS2JoeCS2

    NameLevelCourseJenSeniorCS2JoeJuniorCS1JoeSeniorCS2

  • Query Execution using EddiesEddySECProbe to find matches HashTableS.NameHashTableE.Name E CHashTableE.CourseHashTableC.CourseNo matches; Eddy processesthe next tupleOutputInsert with key hash(joe)

    JoeJunior

    JoeJunior

    JoeJunior

  • Query Execution using EddiesEddySECInsertProbe HashTableS.NameHashTableE.Name HashTableE.CourseHashTableC.CourseOutput

    JoeJr

    JenSr

    JoeCS1

    JoeCS1

    JoeCS1

    JoeJrCS1

    JoeJrCS1

    JoeJrCS1

    CS2Smith

  • Query Execution using EddiesEddySECOutputProbe HashTableS.NameHashTableE.Name HashTableE.CourseHashTableC.CourseProbe

    JoeJr

    JenSr

    CS2Smith

    JenCS2

    JoeCS1

    JoeJrCS1

    JenCS2

    JenCS2

    JenCS2Smith

    JenCS2Smith

    JenCS2Smith

    JenSr.CS2Smith

    JenSr.CS2Smith

  • Eddies: Postmortem (1)Eddy executes different TOBO plans for different parts of dataStudentsEnrolledOutputCoursesE CS ECoursesEnrolledOutputStudentsE SC E

    CourseInstructorCS2Smith

    CourseInstructorCS2Smith

    NameCourseJoeCS1

    NameLevelJoeJuniorJenSenior

    NameLevelJoeJuniorJenSenior

    NameCourseJenCS2

  • Routing Policiesrouting of tuples determines join order

    same policies as described for selectionscan simulate static orderlottery schedulingcan tune policy for interactivity metric [RH02]

    much more work remains to be done

  • SummaryEddies dynamically reorder pipelined operators, on a per-tuple basisselections, nested loop joins, symmetric hash joinsextends naturally to combinations of the above

    This can also be extended to non-pipelined operators (e.g. hybrid hash)

    But, eddy can adapt only when it gets control (e.g., after hash table build)just like with mid-query reoptimization

    Next we study two extensions that widen the plan space still furtherSTAIRs: moving state across join operatorsSteMs: unary operators for adapting access methods, join algorithms dynamically

  • N-way Symmetric Hash JoinPipelined joinXJoin-like disk spilling possible [VNB03]Simplest version atomically does one build + (n-1) probesBreaking this atomicity is key to adaptation

    select * from students, enrolled where students.name = enrolled.nameStudentsEnrolled

    NameLevelJenSeniorJoeJunior

    NameCourseJoeCS1JenCS2JoeCS2

    NameLevelCourseInstructorJenSeniorCS2Prof. BJoeJuniorCS1Prof. AJoeSeniorCS2Prof. B

    CourInstCS1P. ACS2P. B

  • N-way Joins State Modules (SteMs)select * from students, enrolled where students.name = enrolled.nameStudentsEnrolled

    NameLevelJenSeniorJoeJunior

    NameCourseJoeCS1JenCS2JoeCS2

    NameLevelCourseInstructorJenSeniorCS2Prof. BJoeJuniorCS1Prof. AJoeSeniorCS2Prof. B

    CourInstCS1P. ACS2P. B

  • References[A-D03] R. Arpaci-Dusseau. Runtime Adaptation in River. ACM TOCS 2003.[AH00] R. Avnur, J. M. Hellerstein: Eddies: Continuously Adaptive Query Processing SIGMOD Conference 2000: 261-272[Antoshenkov93] G. Antoshenkov: Dynamic Query Optimization in Rdb/VMS. ICDE 1993: 538-547.[BBD05] S. Babu, P. Bizarro, D. J. DeWitt. Proactive Reoptimization. VLDB 2005: 107-118[BBDW05] P. Bizarro, S. Babu, D. J. DeWitt, J. Widom: Content-Based Routing: Different Plans for Different Data. VLDB 2005: 757-768[BC02] N. Bruno, S. Chaudhuri: Exploiting statistics on query expressions for optimization. SIGMOD Conference 2002: 263-274[BC05] B. Babcock, S. Chaudhuri: Towards a Robust Query Optimizer: A Principled and Practical Approach. SIGMOD Conference 2005: 119-130[BMMNW04] S. Babu, et al: Adaptive Ordering of Pipelined Stream Filters. SIGMOD Conference 2004: 407-418[CDHW06] Flow Algorithms for Two Pipelined Filter Ordering Problems; Anne Condon, Amol Deshpande, Lisa Hellerstein, and Ning Wu. PODS 2006.[CDY95] S. Chaudhuri, U. Dayal, T. W. Yan: Join Queries with External Text Sources: Execution and Optimization Techniques. SIGMOD Conference 1995: 410-422[CG94] R. L. Cole, G. Graefe: Optimization of Dynamic Query Evaluation Plans. SIGMOD Conference 1994: 150-160.[CHG02] F. C. Chu, J. Y. Halpern, J. Gehrke: Least Expected Cost Query Optimization: What Can We Expect? PODS 2002: 293-302[CN97] S. Chaudhuri, V. R. Narasayya: An Efficient Cost-Driven Index Selection Tool for Microsoft SQL Server. VLDB 1997: 146-155

  • References (2)[CR94] C-M Chen, N. Roussopoulos: Adaptive Selectivity Estimation Using Query Feedback. SIGMOD Conference 1994: 161-172[DGHM05] A. Deshpande, C. Guestrin, W. Hong, S. Madden: Exploiting Correlated Attributes in Acquisitional Query Processing. ICDE 2005: 143-154[DGMH05] A. Deshpande, et al.: Model-based Approximate Querying in Sensor Networks. In VLDB Journal, 2005[DH04] A. Deshpande, J. Hellerstein: Lifting the Burden of History from Adaptive Query Processing. VLDB 2004.[EHJKMW96] O. Etzioni, et al: Efficient Information Gathering on the Internet. FOCS 1996: 234-243[GW00] R. Goldman, J. Widom: WSQ/DSQ: A Practical Approach for Combined Querying of Databases and the Web. SIGMOD Conference 2000: 285-296[INSS92] Y. E. Ioannidis, R. T. Ng, K. Shim, T. K. Sellis: Parametric Query Optimization. VLDB 1992.[Ives02] Z. G. Ives. Efficient Query Processing for Data Integration. Ph.D., U. Washington, 2002.[K01] M.S. Kodialam. The throughput of sequential testing. In Integer Programming and Combinatorial Optimization (IPCO) 2001.[KBZ86] R. Krishnamurthy, H. Boral, C. Zaniolo: Optimization of Nonrecursive Queries. VLDB 1986.[KD98] N. Kabra, D. J. DeWitt: Efficient Mid-Query Re-Optimization of Sub-Optimal Query Execution Plans. SIGMOD Conference 1998: 106-117[KKM05] H. Kaplan, E. Kushilevitz, and Y. Mansour. Learning with attribute costs. In ACM STOC, 2005.[KNT89] Masaru Kitsuregawa, Masaya Nakayama and Mikio Takagi, "The Effect of Bucket Size Tuning in the Dynamic Hybrid GRACE Hash Join Method. VLDB 1989.

  • References (3)[LEO 01] M. Stillger, G. M. Lohman, V. Markl, M. Kandil: LEO - DB2's LEarning Optimizer. VLDB 2001.[MRS+04] Volker Markl, et al.: Robust Query Processing through Progressive Optimization. SIGMOD Conference 2004: 659-670[MSHR02] S. Madden, M. A. Shah, J. M. Hellerstein, V. Raman: Continuously adaptive continuous queries over streams. SIGMOD Conference 2002: 49-60[NKT88] M. Nakayama, M. Kitsuregawa, and M. Takagi. Hash partitioned join method using dynamic destaging strategy. In VLDB 1988.[PCL93a] H. Pang, M. J. Carey, M. Livny: Memory-Adaptive External Sorting. VLDB 1993: 618-629[PCL93b] H. Pang, M. J. Carey, M. Livny: Partially Preemptive Hash Joins. SIGMOD Conference 1993.[RH05] N. Reddy, J. Haritsa: Analyzing Plan Daigrams of Database Query Optimizers; VLDB 2005.[SF01] M.A. Shayman and E. Fernandez-Gaucherand: Risk-sensitive decision-theoretic diagnosis. IEEE Trans. Automatic Control, 2001.[SHB04] M. A. Shah, J. M. Hellerstein, E. Brewer. Highly-Available, Fault-Tolerant, Parallel Dataflows , SIGMOD, June 2004.[SHCF03] M. A. Shah, J. M. Hellerstein, S. Chandrasekaran and M. J. Franklin. Flux: An Adaptive Partitioning Operator for Continuous Query Systems, ICDE, March 2003.[SMWM06] U. Srivastava, K. Munagala, J. Widom, R. Motwani: Query Optimization over Web Services; VLDB 2006.[TD03] F. Tian, D. J. Dewitt. Tuple Routing Strategies for Distributed Eddies. VLDB 2003.[UFA98] T. Urhan, M. J. Franklin, L. Amsaleg: Cost Based Query Scrambling for Initial Delays. SIGMOD Conference 1998: 130-141[UF 00] T. Urhan, M. J. Franklin: XJoin: A Reactively-Scheduled Pipelined Join Operator. IEEE Data Eng. Bull. 23(2): 27-33 (2000)[VNB03] S. Viglas, J. F. Naughton, J. Burger: Maximizing the Output Rate of Multi-Way Join Queries over Streaming Information Sources. VLDB 2003: 285-296[WA91] A. N. Wilschut, P. M. G. Apers: Dataflow Query Execution in a Parallel Main-Memory Environment. PDIS 1991: 68-77