hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Status of Huawei's 2' Indexing?
Date Mon, 16 Mar 2015 15:40:22 GMT
On Mon, Mar 16, 2015 at 8:14 AM, Michael Segel <michael_segel@hotmail.com>
wrote:

> You’ll have to excuse Andy.
>
> He’s a bit slow.


...


I gave up trying to have an intelligent/civilized conversation with Andrew
> because he just couldn’t grasp the basics.  ;-)
>
>
>
Michael:

Quit insult and ad hominem. Stick to the tech.

St.Ack









>
>
>
> > On Mar 13, 2015, at 4:14 PM, Andrew Purtell <apurtell@apache.org> wrote:
> >
> > When I made that remark I was thinking of a recent discussion we had at a
> > joint Phoenix and HBase developer meetup. The difference of opinion was
> > certainly civilized. (smile) I'm not aware of any specific written
> > discussion, it may or may not exist. I'm pretty sure a revival of
> HBASE-9203
> > would attract some controversy, but let me be clearer this time than I
> was
> > before that this is just my opinion, FWIW.
> >
> >
> > On Thu, Mar 12, 2015 at 3:58 PM, Rose, Joseph <
> > Joseph.Rose@childrens.harvard.edu> wrote:
> >
> >> I saw that it was added to their project. I’m really not keen on
> bringing
> >> in all the RDBMS apparatus on top of hbase, so I decided to follow other
> >> avenues first (like trying to patch 0.98, for better or worse.)
> >>
> >> That Phoenix article seems like a good breakdown of the various indexing
> >> architectures.
> >>
> >> HBASE-9203 (the ticket that deals with 2’ indexes) is pretty civilized
> (as
> >> are most of them, it seems) so I didn’t know there were these
> differences
> >> of opinion. Did I miss the mailing list thread where the architectural
> >> differences were discussed?
> >>
> >>
> >> -j
>
> The opinions expressed here are mine, while they may reflect a cognitive
> thought, that is purely accidental.
> Use at your own risk.
> Michael Segel
> michael_segel (AT) hotmail.com
>
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message