cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6477) Materialized Views (was: Global Indexes)
Date Tue, 14 Jul 2015 15:58:09 GMT


Sylvain Lebresne commented on CASSANDRA-6477:

Ok, let me back up a minute here. If I understand correctly, the current semantic is that
if a view has a non-PK column from the base table, then the MV only has an entry if that non-PK
column is not null? In other words, given:
CREATE TABLE t (k int, t int, v int, PRIMARY KEY (k, t));

INSERT INTO t (k, t, v) VALUES (0, 0, 0) USING TTL 1000;
UPDATE t SET v = null WHERE k = 0 AND t = 0;
If you do:
you get no results, even though the view was created with a {{SELECT *}} and there _is_ a
row in the base table. Is it how this currently work?

Perhaps more importantly, is it how we want it to work?

That is, doesn't it feel a bit inconsistent not to have any entry in the view? That typically
mean that if you query the view to find how many rows have {{t == 0}}, you won't have an accurate
answer in particular. Wouldn't it be better to get:
t | v    | k
0 | null | 0

bq. Because that is the only column which is supported, we TTL the row in the view so that
it is taken care of the same as the base TTL.

Assuming we are fine with the semantic of "the view only has a row if the base class has a
row *and* none of the non-PK columns of the base class that are in the MV Pk are null" (which
I'm not sure I am, and is an important decision for sure), then I think we've be fine with
more than one column on that front by simply using the min TTL of all the columns.

> Materialized Views (was: Global Indexes)
> ----------------------------------------
>                 Key: CASSANDRA-6477
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Jonathan Ellis
>            Assignee: Carl Yeksigian
>              Labels: cql
>             Fix For: 3.0 beta 1
>         Attachments:, users.yaml
> Local indexes are suitable for low-cardinality data, where spreading the index across
the cluster is a Good Thing.  However, for high-cardinality data, local indexes require querying
most nodes in the cluster even if only a handful of rows is returned.

This message was sent by Atlassian JIRA

View raw message