phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: Composite rowkey and salting
Date Mon, 17 Feb 2014 07:52:09 GMT
A skip scan is a point lookup, so you're good now.

Thanks,
James


On Sun, Feb 16, 2014 at 11:21 PM, Skanda <skanda.ganapathy@gmail.com> 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 <jamestaylor@apache.org>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 <
>> skanda.ganapathy@gmail.com> 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 <jamestaylor@apache.org>
>>> Sent: 13-02-2014 00:42
>>>
>>> To: user@phoenix.incubator.apache.org
>>> 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 <skanda.ganapathy@gmail.com>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
>>>>
>>>
>>>
>>
>

Mime
View raw message