Hi Thomas, > I suppose the position of the G(raph) in the index pattern shouldn't matter, since the graph part is not position bound, or does it make a difference to create a SPGO or SGPO index, for example?
SPGO is better than SGPO when you know subject and you know predicate and at the same time you don't know the graph, SGPO is better when you know only S and G but not P. If you know all three then you may choose from primary key GSPO, SPGO and SGPO -- the more selective fields are leading the better. > Besides: in my application I only have one (i.e. the default) graph. Is there a more optimal way to store this, e.g. a Triple structure, while still making use of the existing functions, such as ttlp_mt(...)? Anyway it's impossible to have triples instead of quads in a common storage because system metadata are in system graph. If you really want a triple store it's easy to create it using RDF Views, but it's not very practical because RDF Views are not updateable in current version of Virtuoso so you can create a triple store but can not fill it in with data using existing API. On the other hand, compression will pack repeating graph column into few bytes per page so it's not a noticeable overhead. Best Regards, Ivan Mikhailov, OpenLink Software.
