Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of viral.bajaria@gmail.com
 designates 209.85.219.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D634846B95D967479F3D9764E36EFCF10BF55CA6@MERCMBX14D.na.SAS.com>
References: <D634846B95D967479F3D9764E36EFCF10BF373F9@MERCMBX14D.na.SAS.com>
	<1371854271.43033.YahooMailNeo@web140606.mail.bf1.yahoo.com>
	<DC5EBE7F3610EB4CA5C7E92D76873E1517ECF1DC82@exchange2007.carrieriq.com>
	<1371907440.21443.YahooMailNeo@web140602.mail.bf1.yahoo.com>
	<D634846B95D967479F3D9764E36EFCF10BF3D2A5@MERCMBX14D.na.SAS.com>
	<1372107927.91572.YahooMailNeo@web140605.mail.bf1.yahoo.com>
	<D634846B95D967479F3D9764E36EFCF10BF48315@MERCMBX14D.na.SAS.com>
	<CALte62yyu=2Y9BG_TnHtZoDFDx8S0xwW2XLXrQ+Y+rtqGGFNbQ@mail.gmail.com>
	<D634846B95D967479F3D9764E36EFCF10BF55CA6@MERCMBX14D.na.SAS.com>
Date: Thu, 8 Aug 2013 13:33:01 -0700
Message-ID: 
 <CALckxSPtkNet_FkE62+0eW_UFTJMm1avp=k=qqEzaFZ8NZsSWQ@mail.gmail.com>
Subject: Re: Scan performance
From: Viral Bajaria <viral.bajaria@gmail.com>
To: "user@hbase.apache.org" <user@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2e76a7596cd04e37590f8

--001a11c2e76a7596cd04e37590f8
Content-Type: text/plain; charset=ISO-8859-1

Hi Tony,

I know it's been a while and am not sure if you already figured out the
issue but try taking at HBASE-9079 and see if it's similar to the problem
that you are facing with FuzzyRowFilter. I have attached a patch to that
ticket too and have verified that it fixed things for me in production.

Thanks,
Viral

On Tue, Jul 16, 2013 at 8:07 PM, Tony Dean <Tony.Dean@sas.com> wrote:

> I was able to test scan performance with 0.94.9 with around 6000 rows X 40
> columns and FuzzyRowFilter gave us 2-4 times better performance.  I was
> able to test this offline without any problems.  However, once I turned it
> on in our development cluster, we noticed that with some row keys that
> should have matched were not matching.  After reverting back to
> SingleColumnValueFilter the cases that were failing, began to work again.
>  We thought that the anomaly was due to certain data in row key, but we
> managed to create identical row keys in a different table and see the scan
> work.  So, bottom line I can't explain this behavior.  Has anyone seen this
> behavior and does anyone have debugging tips?
>
> Thanks.
>

--001a11c2e76a7596cd04e37590f8--