We must find a more descriptive way of expressing the cost of iteration than getRowUpperBound()
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