Ticket #23 (new enhancement)

Opened 2 years ago

Last modified 2 years ago

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

Reported by: andrae Assigned to: andrae
Priority: minor Milestone:
Component: Mulgara Version:
Keywords: Cc:

Description

An increasing number of resolvers (relational, federating, distributed) cannot provide a meaningful upper-bound to their row-count.

Also row-count assumes a uniform cost of iteration, when iteration (as opposed to resolution) entails network latency this is unrealistic.

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?