# Erroneous query planning for queries with FROM NAMED declaration and GRAPH variable

**URL:** https://community.stardog.com/t/erroneous-query-planning-for-queries-with-from-named-declaration-and-graph-variable/1710
**Category:** Bug
**Created:** [June 4, 2019, 2:37pm UTC](https://community.stardog.com/t/erroneous-query-planning-for-queries-with-from-named-declaration-and-graph-variable/1710 "2019-06-04T14:37:44Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![mack](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mack](https://community.stardog.com/u/mack)
#### Post date: [June 4, 2019, 2:37pm UTC](https://community.stardog.com/t/erroneous-query-planning-for-queries-with-from-named-declaration-and-graph-variable/1710/1 "2019-06-04T14:37:44Z")

</div>

We encountered a severe query planning error, that can be reproduced  
as follows:

Given an empty database, load the following TriG data

```
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<urn:Beatles> {

<urn:Beatles> a foaf:Group .

<urn:John> a foaf:Person .
<urn:Paul> a foaf:Person .
<urn:George> a foaf:Person .
<urn:Ringo> a foaf:Person .
}

```

Then execute query A:

```
SELECT ?relation ?object ?graph
FROM NAMED <urn:Beatles>
WHERE { 
  GRAPH ?graph { 
    <urn:Beatles> ?relation ?object
  }
}

```

Query A will yield the expected result set of with one solution.

Then execute query B:

```
SELECT ?relation ?object ?graph
FROM NAMED <urn:Beatles>
WHERE { 
  GRAPH ?graph { 
    <urn:John> ?relation ?object
  }
}

```

The expected result set would again contain one solution (the `rdf:type` statement for John),  
but the actual result set is empty. As the query plan shows, Stardog decides for some reason to  
scan the wrong named graph:

```
From Named <urn:Beatles>
Projection(?relation, ?object, ?graph) [#1]
`-- Bind(<urn:John> AS ?graph) [#1]
    `-- Scan[SPO](<urn:John>, ?relation, ?object){<urn:John>} [#1]

```

Additional observations:

This error does not occur if query B is executed at least once before query A.

This error also does not occur if the `?graph` variable is eliminated from the queries, e.g.

```
SELECT ?relation ?object
FROM NAMED <urn:Beatles>
WHERE { 
  GRAPH <urn:Beatles> { 
    <urn:Beatles> ?relation ?object
  }
}

```

and

```
SELECT ?relation ?object
FROM NAMED <urn:Beatles>
WHERE { 
  GRAPH <urn:Beatles> { 
    <urn:John> ?relation ?object
  }
}

```

I was able to reproduce this error on versions 5.3.6, 6.1.0 and 6.2.1.

---

<div class="post-metadata">

### Author: ![stephen](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/stephen/32/27_2.png) [@stephen](https://community.stardog.com/u/stephen)
#### Post date: [June 4, 2019, 2:45pm UTC](https://community.stardog.com/t/erroneous-query-planning-for-queries-with-from-named-declaration-and-graph-variable/1710/2 "2019-06-04T14:45:00Z")

</div>

Hi, and welcome!

Thanks for the very detailed bug report. I seem to be able to reproduce the issue and am opening a ticket to resolve it.

As a workaround, try dropping the database and recreating it with the metadata option `query.plan.reuse=NEVER`

---

<div class="post-metadata">

### Author: ![mack](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mack](https://community.stardog.com/u/mack)
#### Post date: [June 4, 2019, 2:58pm UTC](https://community.stardog.com/t/erroneous-query-planning-for-queries-with-from-named-declaration-and-graph-variable/1710/3 "2019-06-04T14:58:43Z")

</div>

Hi Stephen, thanks for the speedy reply. Switching query plan reuse off circumvents that error indeed.

---

<div class="post-metadata">

### Author: ![mack](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mack](https://community.stardog.com/u/mack)
#### Post date: [June 4, 2019, 5:22pm UTC](https://community.stardog.com/t/erroneous-query-planning-for-queries-with-from-named-declaration-and-graph-variable/1710/4 "2019-06-04T17:22:45Z")

</div>

Can you give a rough estimation/rule of thumb which performance degredation is to be expected when relinquishing the query plan re-use? I could imagine, for example, that some benchmarks have been done on the performance gained when query plan re-use was introduced, which could give an inkling?

---

<div class="post-metadata">

### Author: ![pavel](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pavel/32/18_2.png) [@pavel](https://community.stardog.com/u/pavel)
#### Post date: [June 4, 2019, 5:30pm UTC](https://community.stardog.com/t/erroneous-query-planning-for-queries-with-from-named-declaration-and-graph-variable/1710/5 "2019-06-04T17:30:43Z")

</div>

Hi Markus,

This greatly depends on complexity of your queries for query optimization (not query evaluation), which roughly corresponds to the number and size of BGPs in queries. Stardog tries to reuse query plans for structurally equivalent queries, i.e. those which differ only in constants, and not in structure.

You can run your queries multiple times and see the difference between the first and second evaluations. Of course not all of the difference can be attributed to reusing the cached query plan as evaluation also becomes faster due to warmer data caches, OS caches, and disk caches, but you'll get some idea. You can also try that with and without `query.plan.reuse=NEVER` to see performance difference.

This bug will definitely be fixed before the July's release. We might be able to suggest other workarounds after we dig into the issue.

Cheers,  
Pavel

---

<div class="post-metadata">

### Author: ![pavel](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pavel/32/18_2.png) [@pavel](https://community.stardog.com/u/pavel)
#### Post date: [June 5, 2019, 12:12pm UTC](https://community.stardog.com/t/erroneous-query-planning-for-queries-with-from-named-declaration-and-graph-variable/1710/6 "2019-06-05T12:12:36Z")

</div>

Hi Markus,

Just a quick follow-up to this after we've looked deeper into the issue. The problem can only arise after running a query in which the same constant occurs both in `FROM NAMED` and somewhere else in the query. You can still use the plan cache but you'd need to disable one particular optimization which inlines `FROM NAMED` constants into graph variables. Such things are possible in Stardog by using special hints:

```auto
SELECT ?relation ?object
FROM NAMED <urn:Beatles>
WHERE {
  #pragma optimizer.inline.from off 
  GRAPH <urn:Beatles> { 
    <urn:Beatles> ?relation ?object
  }
}

```

Try this if disabling the cache causes noticeable drop in query throughput, otherwise Stephen's suggestion should work OK for you till July.

Thanks again for the report,  
Pavel

---

<div class="post-metadata">

### Author: ![depressiveRobot](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/depressiverobot/32/74_2.png) [@depressiveRobot](https://community.stardog.com/u/depressiveRobot)
#### Post date: [June 17, 2019, 7:39am UTC](https://community.stardog.com/t/erroneous-query-planning-for-queries-with-from-named-declaration-and-graph-variable/1710/7 "2019-06-17T07:39:55Z")

</div>

Is this problem fixed in the 6.2.2 release?

---

<div class="post-metadata">

### Author: ![pavel](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pavel/32/18_2.png) [@pavel](https://community.stardog.com/u/pavel)
#### Post date: [June 17, 2019, 8:58am UTC](https://community.stardog.com/t/erroneous-query-planning-for-queries-with-from-named-declaration-and-graph-variable/1710/8 "2019-06-17T08:58:29Z")

</div>

We have fixed it in the development branch but it didn't get into 6.2.2 (it was reported just a day before 6.2.2 went out). Will be in the July's release.

Best,  
Pavel