Someone already set the fix version for HBASE-4811 to 0.98. Seems in a reasonable state already based on a skim of the jira comments and the latest trunk patch. Some rebasing will be necessary after HBASE-9245 and subtasks.
On Fri, Aug 23, 2013 at 4:06 PM, James Taylor <[email protected]>wrote: > +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 > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
