We should reuse the CBR costs for single table accesses for the CPU portion, and add the IO costs ourselves.
 
The advantages with this approach are:

1. We will reuse CBR costs for single collection plans which will lead to more consistency between CBR and join costs. We will also get costing for more complex CBR single table access plans, like sort, and_hased, etc., automatically, in addition to any future improvements. 
2. Join cost will strictly be a superset of single collection CBR costs, and therefore the cumulative cost of a join will always be greater than the single collection CBR costs, which is a good property to maintain.

Open questions / ideas:

• Unsure how it will perform for more complex plan fragments like include index intersection, union, sort, group etc. because the join cost model will be assuming that all stages have the same cpuFactor which we know is incorrect.
• One idea could be to measure correlation of exec time vs cost for single table plan fragments that go through the join cost model. But we suspect that the IO costs will largely dominate the CBR portion of the cost, so we’re unclear on how much value we’ll get from that.