On 13 June 2011 17:09, AJ <a...@dude.podzone.net> wrote: > On 6/13/2011 9:25 AM, Stephen Connolly wrote: >> >> On 13 June 2011 16:14, AJ<a...@dude.podzone.net> wrote: >>> >>> On 6/13/2011 7:03 AM, Stephen Connolly wrote: >>>> >>>> It returns the set of columns for the set of rows... how do you >>>> determine the difference between a completely empty row and a row that >>>> just does not have any of the matching columns? >>> >>> I would expect it to not return anything (no row at all) for both of >>> those >>> cases. Are you saying that an empty row is returned for rows that do not >>> match the predicate? So, if I perform a range slice where the range is >>> every row of the CF and the slice equates to no matches and I have 1 >>> million >>> rows in the CF, then I will get a result set of 1 million empty rows? >>> >> No I am saying that for each row that matches, you will get a result, >> even if the columns that you request happen to be empty for that >> specific row. >> > > Ok, this I understand I guess. If I query a range of rows and want only a > certain column and a row does not have that column, I would like to know > that.
deleted rows don't have the column either which is the point. > >> Likewise, any deleted rows in the same row range will show as empty >> because C* would have a tone of work to figure out the difference >> between being deleted and being empty. >> > > But, if a row does indeed have the column, but that row was deleted, why > would I get an empty row? You say because of a ton of work. So, the > tombstone for the row is not stored "close-by" for quick access... or > something like that? At any rate, how do I figure out if the empty row is > empty because it was deleted? Sorry if I'm being dense. > store the query inverted. that way empty -> deleted the tombstones are stored for each column that had data IIRC... but at this point my grok of C* is lacking > >
