+1 Phoenix could leverage this too. On Aug 23, 2013, at 4:04 PM, Dan Burkert <[email protected]> wrote:
> Yep. To support descending sort index scans Honeycomb has to maintain a > separate descending index, which slows down inserts/updates/deletes and > doubles the storage overhead of indices. We would gladly pay a performance > hit for descending scans if it meant not having to store indices twice. > > Descending scans also make sense WRT the new data types API. Currently you > can pick whether you want the type to sort ascending or descending, but if > you need both the only option is to duplicate. Obviously some people may > prefer to scan their data primarily in descending sort, so unless descending > scan speed becomes on-par with ascending it still makes sense to have the > choice. > > -- Dan > > On Aug 23, 2013, at 1:15 PM, Stack <[email protected]> wrote: > >> On Thu, Aug 22, 2013 at 8:41 PM, Dan Burkert <[email protected]> wrote: >> >>> As an interested bystander (user) I would love to see the reverse scan >>> feature (HBASE-4811 (https://issues.apache.org/jira/browse/HBASE-4811)) >>> make 0.98. There has been a lot of talk about HBase indexes lately, and >>> the ability to reverse scan an index opens up a lot of possibilities. >>> >> >> Do you need it for you mysql'ing Dan? >> St.Ack
