Andy thank you, that was very helpful. We don't expect a large amount of data so it doesn't sound like we should be worrying about performance of unionDefaultGraph Guy
From: Andy Seaborne <[email protected]> To: [email protected], Date: 03/10/2013 04:43 PM Subject: Re: unionDefaultGraph performance impact On 03/10/13 14:08, Guy Laden wrote: > > We are considering porting an application that makes use of Sesame to > Fuseki/TDB and it looks like to do so we'd need to enable > unionDefaultGraph. > We would like to understand whether enabling unionDefaultGraph (with TDB) > would have an effect on performance? e.g. additional index lookups/updates? > Thanks, Guy > How much data do you have? Accessing the names graph to form the unionDefaultGraph is done at full speed. It's a bit fo CPU-processing on top of index access. In TDB, there are indexes for a triple table and a quad table. There are no additional indexes for the unionDefaultGraph, which only exists at query time. unionDefaultGraph is achieved by accessing a quad index when a triple index woudl otherwise be used. So to access xyz (e.g. SPO) index, the code goes to xyzG and removes adjacent duplicates (so it appears as a a set of triples). Adjacent duplicate removal is very cheap (there was a fairly recent imporvement in this area to switch to adjacent removal). The costs should be minimal; the indexes aren't as compact so if you were to store all data in one named graph and access as the default graph, it may be a bit slower; you may not be able to notice until you have a lot of data. Overall, the effect should be zero or small. Andy
