This preview shows pages 1–2. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: 136 Chapter 14 would allow an index-only scan, and would thus be just as economical as the clustered index. This method (both by clustered and unclustered ) would cost around 5000 I/O’s. 4. Knowing that duplicate elimination is not required, we can simply scan the relation and discard unwanted fields for each tuple. This is the best strategy except in the case that an index (clustered or unclustered) on < ename, title > is available; in this case, we can do an index-only scan. (Note that even with DISTINCT specified, no duplicates are actually present int he answer because ename is a candidate key. However, a typical optimizer is not likely to recognize this and omit the duplicate elimination step.) Exercise 14.4 Consider the join R./ R.a = S.b S , given the following information about the relations to be joined. The cost metric is the number of page I/Os unless otherwise noted, and the cost of writing out the result should be uniformly ignored. Relation R contains 10,000 tuples and has 10 tuples per page. Relation S contains 2000 tuples and also has 10 tuples per page. Attribute b of relation S is the primary key for S. Both relations are stored as simple heap files. Neither relation has any indexes built on it. 52 buffer pages are available. 1. What is the cost of joining R and S using a page-oriented simple nested loops join? What is the minimum number of buffer pages required for this cost to remain unchanged?...
View Full Document
This note was uploaded on 01/17/2012 for the course EGN 4302 taught by Professor Dr.vishak during the Fall '12 term at University of Central Florida.
- Fall '12