Re: [Bigdata-developers] fast range counts guarantees

[Bryan T. <br...@sy...>]

ZERO is always ZERO.

The BigdataSail.Options.ISOLATABLE_INDICES option enables full read/write
transactions with delete markers.

Bryan

----
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@sy...
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://mapgraph.io

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  MapGraph™ <http://www.systap.com/mapgraph> is our disruptive new
technology to use GPUs to accelerate data-parallel graph analytics.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Mon, Jun 15, 2015 at 2:04 PM, Jeremy J Carroll <jj...@sy...> wrote:

> I am reading the documentation on fast range counts.
>
> [[[
> Fast range counts are exact when running against a BigdataSail on a local
> journal which has been provisioned without full read/write transactions.
> When full read/write transactions are enabled, the fast range counts will
> also report the "delete markers" in the index. In scale-out, the fast range
> counts are also approximate if the key range spans more than one shard (in
> which case you are talking about lot of data).
> ]]]
>
> I am not totally clear what  "provisioned without full read/write
> transactions”; it seems that in either case, the fast range count will
> consistently over-estimate, so that a value of 0 always means 0.
>
> Is this correct? (Just the last statement would be helpful: to know if a
> pattern never matches)
>
> Jeremy
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bigdata-developers mailing list
> Big...@li...
> https://lists.sourceforge.net/lists/listinfo/bigdata-developers
>
>