Remove support for RANGE COLUMNS #64
Description
The implementation for supporting multi-column partition statements via RANGE COLUMNS is inadequate, and it's difficult to fix. The adjustment in #61 broke an assumption that the partition table's positions move in lockstep.
If we have three valued partitions:
- p1 (10,10)
- p2 (20,20)
- p3 (max, max)
Assume our "current position" is (19, 9). Then that position is in p1, and in our mathematical model we derive our rate of change by fitting the current position where it goes in the list.
But in this 2-tuple list, where does it go?
The math right now puts it like:
- p1 (10,10)
- p_now (19,9)
- p2 (20,20)
and then calculates the rate of change as (+9,-1), which gets discarded as a negative rate of change, leading to bad predictions.
The solution is to rewrite the Partition and PositionPartition types to use real positions of the earliest entries in the partition, which is a considerable rewrite in code that is already ... highly evolved from the first iteration.
In the mean time, we're going to stop supporting RANGE COLUMNS because we're doing so poorly, and shouldn't be relied on.