Feature #23
We must find a more descriptive way of expressing the cost of iteration than getRowUpperBound()
Start date:
Due date:
% Done:
0%
Estimated time:
Resolution:
Description
An increasing number of resolvers (relational, federating, distributed) cannot provide a meaningful upper-bound to their row-count.
<br/>
<br/>
Also row-count assumes a uniform cost of iteration, when iteration (as opposed to resolution) entails network latency this is unrealistic.
<br/>
<br/>
How do we handle this? Do we need some sort of bogomips-like timing constant to provide a baseline for comparison? Can we use this to also provide selectivity data that would also improve our join performance?
No data to display