On 04/05/2011 09:57 AM, Jonathan Ellis wrote:
> On Tue, Apr 5, 2011 at 8:54 AM, Jonathan Ellis wrote:
>> Adjusting indexinterval is unlikely to be useful on very narrow rows.
>> (Its purpose is to make random access to _large_ rows doable.)
>
> Whoops, that's column_index_size_in_kb.
>
> I'd pla
On Tue, Apr 5, 2011 at 8:54 AM, Jonathan Ellis wrote:
> Adjusting indexinterval is unlikely to be useful on very narrow rows.
> (Its purpose is to make random access to _large_ rows doable.)
Whoops, that's column_index_size_in_kb.
I'd play w/ keycache before index_interval personally. (If you c
Adjusting indexinterval is unlikely to be useful on very narrow rows.
(Its purpose is to make random access to _large_ rows doable.)
On Mon, Apr 4, 2011 at 8:38 PM, Chris Burroughs
wrote:
> I have a case with very narrow rows. As such I have a large row cache
> that does nicely handles > 50% of
I have a case with very narrow rows. As such I have a large row cache
that does nicely handles > 50% of requests. I think it's likely that
the current tradeoff between page cache and row cache is reasonable.
Using a key cache doesn't make sense in this instance. However, a third
option is to adj
