I've tried to reproduce my test data and the failing queries with stress.py.
So, I've slightly modified the stress.py and added 2 more indexes for
insertion. The indexrangeslice query is also performed on 3 indexes. The
insert is done using an uniform distribution of values.
Then:
1. python cont
Let's start wth the low-hanging fruit: can you give steps to reproduce
queries that fail right away?
On Wed, Nov 17, 2010 at 10:37 AM, dragos cernahoschi
wrote:
> Back. I've tested the keys index pagination once again. 0.7 head. Smaller
> data set: 1 million rows. It seems there are still some is
Back. I've tested the keys index pagination once again. 0.7 head. Smaller
data set: 1 million rows. It seems there are still some issues:
1. *test*: query on one column, count: 1000, expected number of distinct
results: 48251
*result*: 5 pages of 1000 results, than, after the 6th page, the res
On Mon, Nov 15, 2010 at 5:57 AM, dragos cernahoschi
wrote:
> I've tested 0.7-beta3 branch index feature without the 1472 patch. The
> queries on more than one column works better than the patched version, but
> definitely not correctly.
Please test 0.7 branch head, as you can see from the CHANGES
gt; >> > being used yet.
> > >> >
> > >> > To confirm: have you tried the same scenario with KEYS indexes? They
> > use
> > >> > the same codepath for multiple index expressions, and should
> > experience
> > >> the
>
No problem. I'll do the test on Monday.
On Nov 14, 2010 2:35 AM, "Stu Hood" wrote:
> Is it worth testing 0.7-branch-without-1472 to make sure of that?
Dragos: if you have time, this would be helpful. If you already have a KEYS
index created, you shouldn't need to re-load the data, as the file fo
path for multiple index expressions, and should
> experience
> >> the
> >> > same timeouts. Also, can you rerun the KEYS_BITMAP test with DEBUG
> >> logging
> >> > enabled, to ensure that we aren't going into some kind of infinite
> loop?
> >&g
sure that we aren't going into some kind of infinite loop?
>> >
>> > Thanks for the help,
>> > Stu
>> >
>> > -Original Message-
>> > From: "dragos cernahoschi"
>> > Sent: Tuesday, November 9, 2010 11:50am
>> >
BUG
> logging
> > enabled, to ensure that we aren't going into some kind of infinite loop?
> >
> > Thanks for the help,
> > Stu
> >
> > -Original Message-
> > From: "dragos cernahoschi"
> > Sent: Tuesday, November 9, 2010 11:
x27;t going into some kind of infinite loop?
>
> Thanks for the help,
> Stu
>
> -Original Message-
> From: "dragos cernahoschi"
> Sent: Tuesday, November 9, 2010 11:50am
> To: dev@cassandra.apache.org
> Subject: Re: CASSANDRA-1472 (bitmap indexes)
>
> I
of infinite loop?
>
> Thanks for the help,
> Stu
>
> -Original Message-
> From: "dragos cernahoschi"
> Sent: Tuesday, November 9, 2010 11:50am
> To: dev@cassandra.apache.org
> Subject: Re: CASSANDRA-1472 (bitmap indexes)
>
> I'm running the qu
ks for the help,
Stu
-Original Message-
From: "dragos cernahoschi"
Sent: Tuesday, November 9, 2010 11:50am
To: dev@cassandra.apache.org
Subject: Re: CASSANDRA-1472 (bitmap indexes)
I'm running the query on three columns with cardinalities: 22, 17 and 10.
Interesting,
>
> Thanks!
>
>
> -Original Message-
> From: "dragos cernahoschi"
> Sent: Tuesday, November 9, 2010 10:14am
> To: dev@cassandra.apache.org
> Subject: Re: CASSANDRA-1472 (bitmap indexes)
>
> Meantime the number of SSTable(s) reduced to just 7. Initiall
-
From: "dragos cernahoschi"
Sent: Tuesday, November 9, 2010 10:14am
To: dev@cassandra.apache.org
Subject: Re: CASSANDRA-1472 (bitmap indexes)
Meantime the number of SSTable(s) reduced to just 7. Initially the
compaction thread suffered the same problem of "too many open files"
Interesting... thanks for the report! I'll see if I can reproduce.
-Original Message-
From: "dragos cernahoschi"
Sent: Tuesday, November 9, 2010 10:14am
To: dev@cassandra.apache.org
Subject: Re: CASSANDRA-1472 (bitmap indexes)
Meantime the number of SSTable(s) re
dex
> for each sstable: if it finds matches it will need to seek to find them in
> the primary index, and seek again for the data file.
>
> -Original Message-
> From: "dragos cernahoschi"
> Sent: Tuesday, November 9, 2010 5:33am
> To: dev@cassandra.apache.org
>
finds matches it will need to seek to find them in the
primary index, and seek again for the data file.
-Original Message-
From: "dragos cernahoschi"
Sent: Tuesday, November 9, 2010 5:33am
To: dev@cassandra.apache.org
Subject: Re: CASSANDRA-1472 (bitmap indexes)
There are
There are about 500 SSTables (12GB of data including index data,
statistics...) The source data file had about 3GB/26 million rows.
I only test with EQ expressions for now.
Increasing the file limit resolved the problem, but now I'm getting
TimedOutException(s) from thrift when "querying" even wi
Dragos,
How many SSTables did you have on disk, and were any of your index expressions
GT(E)/LT(E)?
I expect that you are bumping into a limitation of the current implementation:
it opens up to 128 file-handles per SSTable in the worst case for a GT/LT query
(one per index bucket).
A future v
19 matches
Mail list logo
