Re: [Bigdata-developers] FILTER EXISTS and || vs UNION

[Mike P. <mi...@sy...>]

Jeremy-

None of the three are obviously better than the others.  I'd probably just
choose option (2), but I'd certainly test all three.  I suspect (3) will
be the slowest because my guess is that it will expand to two subqueries.
I don't think any of them will only run one or the other pattern and abort
at first success - I can't think of a clever way to do that offhand but I
will think on it some more.

-Mike


On 5/2/14 12:13 PM, "Jeremy J Carroll" <jj...@sy...> wrote:

>I implement fine grained access control using additional conditions that
>must hold on most queries: the corresponding SPARQL patterns get inserted
>into (nearly) all queries at the right point(s).
>
>This is using a match that is currently expressed as a UNION, and I am
>using a SELECT DISTINCT effectively the same as a FILTER EXISTS to make
>sure that at least one of the conditions in the union hold.
>
>I can see three different ways of expressing this Š (I simplify the
>example)
>
>
>1)
>
>pattern binding ?foo
>
>{ SELECT DISTINCT ?foo {
>   { ?foo eg:p eg: a } UNION { ?foo eg:q eg:b }
>} }
>   
>2)
>pattern binding ?foo
>
>FILTER EXISTS {
>   { ?foo eg:p eg: a } UNION { ?foo eg:q eg:b }
>} 
>
>3)
>
>pattern binding ?foo
>
>FILTER EXISTS  { ?foo eg:p eg: a } || EXISTS { ?foo eg:q eg:b }
>
>where actually I have three alternatives on my union, and two of them are
>three triple matches
>
>Is any one of these likely to be faster than the others Š (I do this a
>lot). In particular, one implementation might  evaluate in parallel, and
>abort as soon as one of the alternatives is true.
>
>I guess also, if one of these constructs is better, should we have an
>optimizer that maps the other(s) into it.
>
>[I have already convinced myself that:
>a) for my data I wish this to be done after ?foo is bound rather than
>before
>b) I need to use query hints or explicit management of named subqueries
>or similar to ensure that this happens
>c) at some point in the future (a) and (b) may not be optimal for my
>application (e.g. when we have a lot of users and each user has
>relatively small amounts of data, and has privacy set fairly high: the
>FILTER implements our fine-grained access control), but we will cross
>that bridge when we get to it
>]
>
>Jeremy
>
>
>
>
>--------------------------------------------------------------------------
>----
>"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>Instantly run your Selenium tests across 300+ browser/OS combos.  Get
>unparalleled scalability from the best Selenium testing platform
>available.
>Simple to use. Nothing to install. Get started now for free."
>http://p.sf.net/sfu/SauceLabs
>_______________________________________________
>Bigdata-developers mailing list
>Big...@li...
>https://lists.sourceforge.net/lists/listinfo/bigdata-developers