Thank you for your reply, Stack. And Sorry for my late reply. Actually I overlooked your reply..
> I tried to add a server-side check to forbid such scans, but as James > mentioned in the Jira, this would have negative implications on performance. > > Which 'performance' I wonder? I’m sorry I didn't explain it clearly enough. Originally, I faced the issue when using Phoenix, which is explained by PHOENIX-4658. When running the SELECT query In the Jira, Phoenix tries to do a reverse scan and the loadColumnFamiliesOnDemand optimization, and then the IllegalStateException occurs. To avoid the IllegalStateException when running such a query, we have to disable the loadColumnFamiliesOnDemand optimization, but it can imply performance nagativly for some cases. > It'd be a big job given plumbing for going in reverse is just absent > (Reverse Scan is just a fake on top of forward Scanning; it is not even > complete just reversing on rows, not on columns in a row...). You'd add > reverse on indices in blocks and the notion of 'previous' to Scanners and > Streams. It'd be slow given buffering and seeks 'naturally' are aimed in > the forward direction. I understood that we need to add and modify a lot of code to support seek for a reverse scan. Thanks, Toshihiro Suzuki > On Apr 1, 2018, at 14:27, Stack <st...@duboce.net> wrote: > > On Wed, Mar 28, 2018 at 11:31 PM, Toshihiro Suzuki <brfrn...@gmail.com> > wrote: > >> Hi folks, >> >> We are facing “IllegalStateException: requestSeek cannot be called on >> ReversedKeyValueHeap" when using a reverse scan and the >> loadColumnFamiliesOnDemand optimization is enabled. As ReversedKeyValueHeap >> doesn't support requestSeek, it seems like the IllegalStateException >> occurs. I have already filed this issue to HBASE-20219, please see it for >> the details. >> >> Yeah, that seems right given how reverse is 'implemented' (or, to be more > correct, not implemented). > > > >> I tried to add a server-side check to forbid such scans, but as James >> mentioned in the Jira, this would have negative implications on performance. >> >> Which 'performance' I wonder? > > > >> I think the best solution is to make ReversedKeyValueHeap support seek if >> we can. What do you guys think about the feasibility of this? >> > > > It'd be a big job given plumbing for going in reverse is just absent > (Reverse Scan is just a fake on top of forward Scanning; it is not even > complete just reversing on rows, not on columns in a row...). You'd add > reverse on indices in blocks and the notion of 'previous' to Scanners and > Streams. It'd be slow given buffering and seeks 'naturally' are aimed in > the forward direction. > > Thanks, > > S > > > >> Thanks, >> Toshihiro Suzuki >> >>