An Overview of Eddies and STAIRs

In databases where different resources have much changing characteristics, static query plans is often not a good solution. The problem is that, while a particular query plan might be a good alternative with some initial characteristics of the database, it may be a bad alternative when the characteristics changes. Consider, for example, joining the tables R, S and T , and assume first that R and S contain 1000 rows and T contains 10 rows. Clearly, it is best to not use the join ordering (R on S) on T but to choose any other ordering such as (T on R) on S. However, if the size of T drastically increases to 1, 000, 000 rows, this is not a good choice anymore. In this overview we present the ideas of [1, 2] which suggests two adaptive query operators called Eddies and STAIRs. Using these operators instead of traditional ones, the query plans need not be fixed, but can be changed on a tuple-by-tuple basis. In the following, Section 2 starts by presenting the Eddy operator and discuss some of its shortcomings. After that, Section 3 presents the STAIR operator and how it can be used to overcome these shortcomings. Finally, Section 4 concludes the overview. For in-depth information about Eddies and STAIRs see [1, 2].