Hi all, I am using Virtuoso build having SHA = b86c2a70106138325ed53c60690d7c8f79bc5446 and I found a weird behaviour in the queries making use of literals. Basically, the problem is that the query plan changes with no apparent reason depending on whether the same query is run immediately after starting the server or some time (and queries) later, and such change causes a difference in the execution time (the first time the query is faster).
The query has the following pattern: SELECT * WHERE { ?id <http://example.com#relation> "Some text" . ?id <http://example.com#relation> "Some other text" . } You can find the two different query plans in the bottom, the former being the "fast" one and the latter being the "slow" one. What's even more strange is that, if the literals are moved in a FILTER clause and "cast" using the STR() function, the query is always executed in "fast mode". In other words, if the query is written in this way, the plan does not change (last query plan in the bottom): SELECT * WHERE { ?id <http://example.com#relation> "Some text" . ?id <http://example.com#relation> ?o . FILTER(STR(?o) = "Some other text") } It looks like the main difference, besides the FILTER addition (the "After test" block), is the presence of the "inlined" keyword and the use of the RDF_QUAD index rather than the POGS index. Can you explain what's happening with the indices and what does the "inlined" keyword mean? Thank you, Nicola ------------------------------------- First ("fast") query plan: { time 0.038% fanout 1 input 1 rows time 1% fanout 902 input 1 rows Precode: 0: __rdflit := Call __rdflit (rdflit6325) 5: __rdflit := Call __rdflit (rdflit1206) 10: BReturn 0 RDF_QUAD_POGS 9e+02 rows(s_9_4_t0.S) P = ##relation , O = rdflit6325 time 99% fanout 0.00776053 input 902 rows RDF_QUAD 0.01 rows() inlined P = ##relation , S = s_9_4_t0.S , O = rdflit1206 After code: 0: id := Call __id2in (s_9_4_t0.S) 5: BReturn 0 time 0.016% fanout 0 input 7 rows Select (id) } 8 msec 40% cpu, 917 rnd 1810 seq 0% same seg 80.8279% same pg 513 disk reads, 508 read ahead, 29.745% wait Compilation: 13 msec 702 reads 25.6666% read 0 messages 0% clw ------------ Second ("slow") query plan: { time 4.6e-05% fanout 1 input 1 rows time 0.001% fanout 902 input 1 rows Precode: 0: __rdflit := Call __rdflit (rdflit6325) 5: __rdflit := Call __rdflit (rdflit1206) 10: BReturn 0 RDF_QUAD_POGS 0.065 rows(s_9_4_t0.S) P = ##relation , O = rdflit6325 time 1e+02% fanout 0.00776053 input 902 rows RDF_QUAD_POGS 4.6e-14 rows() P = ##relation , O = rdflit1206 S = s_9_4_t0.S After code: 0: id := Call __id2in (s_9_4_t0.S) 5: BReturn 0 time 2e-05% fanout 0 input 7 rows Select (id) } 5995 msec 99% cpu, 903 rnd 1.37377e+08 seq 0% same seg 0% same pg Compilation: 1 msec 0 reads 0% read 0 messages 0% clw ------------- Plan with FILTER and STR(): { time 0.12% fanout 1 input 1 rows time 3.1% fanout 902 input 1 rows Precode: 0: __rdflit := Call __rdflit (rdflit6325) 5: BReturn 0 RDF_QUAD_POGS 0.065 rows(s_5_4_t0.S) P = ##relation , O = rdflit6325 time 47% fanout 1.01663 input 902 rows RDF_QUAD 0.46 rows(s_5_4_t1.O) inlined P = ##relation , S = s_5_4_t0.S time 50% fanout 0.00763359 input 917 rows END Node After test: 0: __rdf_strsqlval := Call __rdf_strsqlval (s_5_4_t1.O, 0 ) 5: if (<c Some other text> = __rdf_strsqlval) then 9 else 10 unkn 10 9: BReturn 1 10: BReturn 0 After code: 0: id := Call __id2in (s_5_4_t0.S) 5: o := Call __ro2sq (s_5_4_t1.O) 10: BReturn 0 time 0.0084% fanout 0 input 7 rows Select (id, o) } 2 msec 67% cpu, 1827 rnd 2461 seq 0% same seg 40.5908% same pg Compilation: 1 msec 0 reads 0% read 0 messages 0% clw ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users