-
Notifications
You must be signed in to change notification settings - Fork 75
FR: Use composite indexes in the query planner #183
Comments
Not sure about that. Composite indices are supported but not yet used beyond enforcing the UNIQUE constraint. I think that the only missing piece is to teach the planner to use composite indices at all. Do you feel like giving it a try? 😉 |
I would like to. I am trying to wrap my head around the internals ATM. From what I can tell, I need to:
Is this correct? Where in the codebase are the composite indexes written to? |
From the top of my head: yes.
These interface methods are of your interest
Look for the implemetations of the above in {file,mem}.go |
Ok thanks. I'm still getting the lay of the land a little, one more set of conclusions it would be helpful if you could double check. This is my end-to-end understanding of a QL statement execution:
Based on this, I think I only need to modify the logic in |
Will do, but only later today as I don't want to mislead you by providing a quick, but incorrect answer.
Sounds easy, which is in my experience seldom confirmed when actually implementing the plan ;-) |
Yes, it's an AST, nodes are
Seems correct.
Ditto. Even if I really tried to verify the correctness of your understanding, it's a long time the code was written. Apologies if I've got something wrong. |
The idea behaviour would be for x to be a composite index, and for it to be used for all queries which have comparisons to
thing
andt
.This is a very common pattern for most customer-facing databases, where you need to filter on (at minimum) a user identifier and a timestamp, which should ideally have
O(log n)
performance (a customer with 1mil records should minimially impact the performance of another customer with only a few hundred records).Based on my reading of
ql/design
implementing this is not possible without changing the low-level table representation.The text was updated successfully, but these errors were encountered: