Project

General

Profile

Feature #23

We must find a more descriptive way of expressing the cost of iteration than getRowUpperBound()

Added by Andrae Muys - about 16 years ago. Updated about 16 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
Mulgara
Target version:
-
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

Also available in: Atom PDF