Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove support for RANGE COLUMNS #64

Open
jcjones opened this issue Apr 14, 2023 · 0 comments
Open

Remove support for RANGE COLUMNS #64

jcjones opened this issue Apr 14, 2023 · 0 comments

Comments

@jcjones
Copy link
Collaborator

jcjones commented Apr 14, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant