Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 798F3D319 for ; Mon, 19 Nov 2012 07:12:43 +0000 (UTC) Received: (qmail 35957 invoked by uid 500); 19 Nov 2012 07:12:41 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 35770 invoked by uid 500); 19 Nov 2012 07:12:39 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 35725 invoked by uid 99); 19 Nov 2012 07:12:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Nov 2012 07:12:37 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of owenzhang1990@gmail.com designates 74.125.83.44 as permitted sender) Received: from [74.125.83.44] (HELO mail-ee0-f44.google.com) (74.125.83.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Nov 2012 07:12:32 +0000 Received: by mail-ee0-f44.google.com with SMTP id b47so2963942eek.31 for ; Sun, 18 Nov 2012 23:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=oHW1+A9IncbuguMKYsZxZVTivqcBtZmrig6jBQLCUEM=; b=vfZvBPpA2GlK8l8TldnLp4hXKYm2uY58aLDMRDK3v3CsAXUjVnGzpzjI+TZVzAHHdk NmNCZEeIAw6dl0LOKD04Sgk1td4DXwsx9fPIhrekCYbjw0iTUeksRS77jZyqCO9x3hdd jnSVqKZDJa9WaabCTg59UMNU7+lt52RYXEAUSxvPviZFTYUgCDyv2qDQrcZ2KrM5KNl1 d7mppyZ80qOoGLTK9BEwI/w6ZmpEb4SarR+nYBuTmNB959oPUskyzJnTM3G04zvIHsCE MaqwPDKBu0a4QtcqyIejdq4zPWkQTkRnXt3wyT1cG0gSs5G/xZCJbXiP8YqY+Cm6Ff1k View== MIME-Version: 1.0 Received: by 10.14.175.198 with SMTP id z46mr21261524eel.26.1353309131434; Sun, 18 Nov 2012 23:12:11 -0800 (PST) Received: by 10.14.127.133 with HTTP; Sun, 18 Nov 2012 23:12:11 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Nov 2012 15:12:11 +0800 Message-ID: Subject: Re: get_range_slice gets no rowcache support? From: Manu Zhang To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=047d7b603e740ceb0f04ced3d61a X-Virus-Checked: Checked by ClamAV on apache.org --047d7b603e740ceb0f04ced3d61a Content-Type: text/plain; charset=ISO-8859-1 yes, https://issues.apache.org/jira/browse/CASSANDRA-1302 thanks On Wed, Nov 14, 2012 at 2:04 AM, Tyler Hobbs wrote: > As far as I know, the row cache has never been populated by > get_range_slices(), only normal gets/multigets. The behavior is this way > because get_range_slices() is almost exclusively used to page over an > entire column family, which generally would not fit into the cache and > would simply a) ruin your cache if used for gets (b) generate a lot of > extra garbage, and (c) result in nothing but cache misses. > > With that said, I'm sure there are still a few use cases where using the > cache would be beneficial, so I'm sure there's a ticket out there somewhere > that presents a few options for supporting this. > > > On Thu, Nov 8, 2012 at 8:39 PM, Manu Zhang wrote: > >> I did overlook something. get_range_slice will invoke cfs.getRawCachedRow >> instead of cfs.getThroughCache. Hence, no row will be cached if it's not >> present in the row cache. Well, this puzzles me further as to that how the >> range of rows is expected to get stored into the row cache in the first >> place. >> >> Would someone please clarify it for me? Thanks in advance. >> >> >> On Thu, Nov 8, 2012 at 3:23 PM, Manu Zhang wrote: >> >>> I've asked this question before. And after reading the source codes, I >>> find that get_range_slice doesn't query rowcache before reading from >>> Memtable and SSTable. I just want to make sure whether I've overlooked >>> something. If my observation is correct, what's the consideration here? >> >> >> > > > -- > Tyler Hobbs > DataStax > > --047d7b603e740ceb0f04ced3d61a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yes,=A0htt= ps://issues.apache.org/jira/browse/CASSANDRA-1302=A0
thanks


On Wed, Nov 14,= 2012 at 2:04 AM, Tyler Hobbs <tyler@datastax.com> wrote:
As far as I know, the row cache has never be= en populated by get_range_slices(), only normal gets/multigets.=A0 The beha= vior is this way because get_range_slices() is almost exclusively used to p= age over an entire column family, which generally would not fit into the ca= che and would simply a) ruin your cache if used for gets (b) generate a lot= of extra garbage, and (c) result in nothing but cache misses.

With that said, I'm sure there are still a few use cases where usin= g the cache would be beneficial, so I'm sure there's a ticket out t= here somewhere that presents a few options for supporting this.


On Thu, Nov 8, 2012 at 8:39 PM, Manu Zha= ng <owenzhang1990@gmail.com> wrote:
I did overlook something. get_range_slice will invoke cfs.getRawCachedRow i= nstead of cfs.getThroughCache. Hence, no row will be cached if it's not= present in the row cache. Well, this puzzles me further as to that how the= range of rows is expected to get stored into the row cache in the first pl= ace.

Would someone please clarify it for me? Thanks in advance.


On Thu, Nov 8, 2012 at 3:23 PM, Manu Zhang <owenzhang1990@gmail.c= om> wrote:
I've asked this question before. And aft= er reading the source codes, I find that get_range_slice doesn't query = rowcache before reading from Memtable and SSTable. I just want to make sure= whether I've overlooked something. If my observation is correct, what&= #39;s the consideration here?




--
Tyl= er Hobbs
DataStax
<= br>

--047d7b603e740ceb0f04ced3d61a--