Consider the condition join RR$1.$a$=$R$2.$b$)$R$2,$ given the following information

about the relations to be joined. The cost$-$metric is the number of IOs. The cost of

writing the result would be the same independent of the particular join method used,

hence we henceforth can ignore it$.$ Given:

R$1$ has $10,000$ tuple, $10$ tuples per block

R$2$ has $2,000$ tuple, $10$ tuples per block

The available memory buffers are $52$

Assume we use a block$-$oriented nested loop join.

a$.$ Which relation you suggest to be the outer relation?

b$.$ What is the cost of the join if we use the outer relation as you suggested?

c$.$ What is the cost of the join if we use the other relation $($not what you suggestion$)$ as the outer one?

Assume we use a sort$-$merge join, and we use the "Efficient Sort$-$Merge" algorithm covered in class where we

merge the sorting and joining together

a$.$ What is the cost of the join algorithm?

b$.$ What is the minimum number of buffers needed for the cost to remain unchanged, i$.$e$.,$ Can we use less than

$52$ buffers and still have the same cost that you calculated in $2.$a$?$

Assume we use a hash$-$join, and we will do a simple hash$-$join.

a$.$ What is the cost of the join algorithm?

b$.$ What is the minimum number of buffers needed for the cost of the hash join to remain unchanged, i$.$e$.,$ Can

we use less than $52$ buffers and still have the same cost that you calculated in $3.$a$?$

$4.$ Assume we use an index$-$join with R$2$ as the outer relation, and we have an index on R$1.$a$.$ Assume that the index fits in memory. Moreover, on average we get $5$ R$1$ tuples matching every R$2$ tuple.

a$.$ What is the cost of the join algorithm?

Here you might need to make assumptions i$.$e$.$ one or both tables are clustered $($or not$),$ or index is clustered or not, index in memory or not, etc.