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 >>> >> >> >
