AFAIK there is no way to disable hoisting.
Feel free to let your jira fingers do the talking.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 18/12/2012, at 6:10 PM, Edward Capriolo edlinuxg...@gmail.com wrote:
Thank you Aaron, this was very helpful.
Could it be an issue that this optimization does not really take effect
until the memtable with the hoisted data is flushed? In my simple
example below, the same row is updated and multiple selects of the same
row will result in multiple writes to the
Could it be an issue that this optimization does not really take effect until
the memtable with the hoisted data is flushed?
No.
The read path in collectTimeOrderedData() reads from the memtable first. It
then reads the SStable meta data (maxTimestamp) and checks if the candidate
columns are
Is there a way to turn this on and off through configuration? I am not
necessarily sure I would want this feature. Also it is confusing if these
writes show up in JMX and look like user generated write operations.
On Mon, Dec 17, 2012 at 10:01 AM, Mike mthero...@yahoo.com wrote:
Thank you
1) Am I reading things correctly?
Yes.
If you do a read/slice by name and more than min compaction level nodes where
read the data is re-written so that the next read uses fewer SSTables.
2) What is really happening here? Essentially minor compactions can occur
between 4 and 32 memtable
Hello,
We have an unusual situation that I believe I've reproduced, at least
temporarily, in a test environment. I also think I see where this issue is
occurring in the code.
We have a specific column family that is under heavy read and write load on a
nightly basis. For the purposes of
