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.