A skip scan is a point lookup, so you're good now. Thanks, James
On Sun, Feb 16, 2014 at 11:21 PM, Skanda <[email protected]> wrote: > Hi James, > > I tried the fix for point lookup on salted tables with the latest 2.2.3 > build. The plan still shows SKIP SCAN instead of a point lookup for a > salted table with a single PK. > > +------------+ > | PLAN | > +------------+ > | CLIENT PARALLEL 3-WAY SKIP SCAN ON 3 KEYS OVER test1 [0,'abc'] - > [2,'abc'] | > | CLIENT MERGE SORT | > > Regards, > Skanda > > > > On Thu, Feb 13, 2014 at 1:16 AM, James Taylor <[email protected]>wrote: > >> Yes, I believe the fix will help also in the case of a partial match on >> primary key columns. But the particular case I tested was a complete match >> on a composite primary key, in which case the salt byte is known. On a >> partial match, we'd do skip scans for each salt bucket and then do a merge >> sort on the results. By default, if your leading column in your primary key >> constraint isn't used in the query, a skip scan won't be done. Sometimes, >> depending on the cardinality of the column values, it'd be better if it >> did. You can override this with the SKIP_SCAN hint. There's a bit more >> detail here: >> http://phoenix.incubator.apache.org/faq.html#/Why_isnt_my_query_doing_a_RANGE_SCAN >> >> Thanks, >> James >> >> >> On Wed, Feb 12, 2014 at 11:26 AM, Skanda Prasad < >> [email protected]> wrote: >> >>> Hi James, >>> >>> Does the fix work for a composite key? The reason I'm asking this >>> question is that the salt is generated using composite key (x,y) but >>> when I just look up on x, is it possible to identify the bucket? Please >>> correct me if I'm wrong.. >>> >>> Thanks, >>> Skanda >>> ------------------------------ >>> From: James Taylor <[email protected]> >>> Sent: 13-02-2014 00:42 >>> >>> To: [email protected] >>> Subject: Re: Composite rowkey and salting >>> >>> Hi Skanda, >>> Yes, there was actually a bug here that was preventing a point lookup >>> for salted tables: https://issues.apache.org/jira/browse/PHOENIX-20 >>> >>> It's been fixed and is in our release candidate build for 2.2.3. Would >>> be great if you could verify that this solves your issue. >>> >>> Thanks, >>> James >>> >>> >>> On Wed, Feb 12, 2014 at 10:46 AM, Skanda <[email protected]>wrote: >>> >>>> Hi >>>> Assume I have a table with composite keys, say (x,y) salted into 3 >>>> buckets. I understand that the salt is prepended to the actual rowkey. Now >>>> when I try to lookup the table for x, will phoenix still do a range scan in >>>> 3 regions to fetch the result? How is the hash derived, using x or x,y? >>>> Ideally I want to specify the hash component of the composite key,in this >>>> case x thereby ensuring identical x's fall into the same region.Is it >>>> possible in phoenix? >>>> >>>> Regards, >>>> Skanda >>>> >>> >>> >> >
