Currently the LimitSkipByIndexPass will look for an existing IndexRangeScanStep in the execution tree
- if it finds one, it will try to leverage it to perform limit/skip using the index
- if it does not find one, it does nothing.
For this query, because there is no predicate, an IndexRangeScanStep does not exist in the tree, but instead of
concluding that the optimization is not applicable, we should check if the table has a primary key. If it does, then
use the primary key's index to perform LIMIT/SKIP.
Currently the LimitSkipByIndexPass will look for an existing IndexRangeScanStep in the execution tree
For this query, because there is no predicate, an IndexRangeScanStep does not exist in the tree, but instead of
concluding that the optimization is not applicable, we should check if the table has a primary key. If it does, then
use the primary key's index to perform LIMIT/SKIP.