of course. compaction is always O(N) with the size of the data On Mon, Jun 7, 2010 at 9:51 AM, Jeremy Davis <jerdavis.cassan...@gmail.com> wrote: > Reads, ok.. What about Compactions? Is the cost of compacting going to be > ever increasing with the number of columns? > > > > On Sat, Jun 5, 2010 at 7:30 AM, Jonathan Ellis <jbel...@gmail.com> wrote: >> >> #16 is very simple: it allows you to make very large rows. That is all. >> >> Other things being equal, doing reads from really big rows will be >> slower (since the row index will take longer to read) and this patch >> does not change this. >> >> On Fri, Jun 4, 2010 at 5:47 PM, Jeremy Davis >> <jerdavis.cassan...@gmail.com> wrote: >> > >> > https://issues.apache.org/jira/browse/CASSANDRA-16 >> > >> > Can someone (Jonathan?) help me understand the performance >> > characteristics >> > of this patch? >> > Specifically: If I have an open ended CF, and I keep inserting with ever >> > increasing column names (for example current Time), will things >> > generally >> > work out ok performance wise? Or will I pay some ever increasing penalty >> > with the number of entries? >> > >> > My assumption is that you have bucketed things up for me by column name >> > order, and as long as I don't delete/modify/create a column in one of >> > the >> > old buckets, then things will work out ok. Or is this not at all what is >> > going on? >> > >> > Thanks, >> > -JD >> > >> >> >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder of Riptano, the source for professional Cassandra support >> http://riptano.com > >
-- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
