Add constant time out-of-date count(). about rethinkdb HOT 4 CLOSED

Depending on what you mean by out-of-date count, I think count command itself should be out-of-date. It essentially already is because of the traversal -- while the system runs the traversal to count the number of keys, the user may insert or delete keys which count won't see. Since there are no cluster-wide snapshot isolation guarantees here, and the traversal may take a long time, our current count is technically more "out-of-date" than an out-of-date constant time count would be.

As long as we still go to the masters to grab the number per b-tree (so there is no chance of getting it from a heavily out-of-date replica on a net split), it should just be done as the count command. If the user passes an out-of-date flag, we should do it from the replicas. And we should drop the traversal version of count all together.

from rethinkdb.

I think up-to-date might be getting a bit conflated right now.

Count is an up-to-date command by default right now (like every command in reql). This means that it may interleave with commands from other connections but it is guaranteed to see anything that has been acknowledged on the same connection. That is you can't take an empty table, insert a document on a connection do count and get back 0 (all on the same connection). I think we want to keep this as a guaranteed behavior since we advertise it heavily and people could be depending on it.

As long as we still go to the masters to grab the number per b-tree (so there is no chance of getting it from a heavily out-of-date replica)

Remember masters don't actually store a copy of the data. Replicas do. There's a replica on the same machine as the master which is I assume what you're talking about but that replica is the same as every other replica it's not guaranteed to be anymore up to date. In fact in this case it's going to almost certainly be the least up-to-date replica.

And we should drop the traversal version of count all together.

We can't drop traversal version of count all together because we still need it for anything that isn't just a simple table traversal. For example if someone does

table.filter(lambda x: x["foo"] == 5).count()

We don't have any prestored counts which will tell us the answer to this so we need to just do the traversal version of count.

from rethinkdb.

Moving to 1.14-polish. This isn't as important as major features, and I'd like to agree on those first. We can tackle this later.

from rethinkdb.

Closing in favor of #152. There is no reason to have two issues for this.

from rethinkdb.