Re: [Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

2013-05-27 Thread Vishesh Handa
On Mon, May 27, 2013 at 11:26 PM, Volker Krause wrote: > On Sunday 26 May 2013 23:27:26 Vishesh Handa wrote: > > On Sun, May 26, 2013 at 6:19 PM, Volker Krause wrote: > > > There are some general reasons for the extra server process: > > > - abstracting the database backend, hardly any of them a

Re: [Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

2013-05-27 Thread Volker Krause
On Sunday 26 May 2013 23:27:26 Vishesh Handa wrote: > On Sun, May 26, 2013 at 6:19 PM, Volker Krause wrote: > > There are some general reasons for the extra server process: > > - abstracting the database backend, hardly any of them are actually > > compatible > > on the SQL level, and if they are

Re: [Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

2013-05-27 Thread Vishesh Handa
On Mon, May 27, 2013 at 2:28 PM, Sebastian Trüg wrote: > On 05/26/2013 12:58 AM, Vishesh Handa wrote: > >> Hey guys >> >> I have made a very important discovery - The Storage service is a big >> bottleneck! >> >> Running a query such as - 'select * where { graph ?g { ?r ?p ?o. } } >> LIMIT 5'

Re: [Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

2013-05-27 Thread Ignacio Serantes
Sounds good for me. On Sun, May 26, 2013 at 12:58 AM, Vishesh Handa wrote: > Hey guys > > I have made a very important discovery - The Storage service is a big > bottleneck! > > Running a query such as - 'select * where { graph ?g { ?r ?p ?o. } } LIMIT > 5' by directly connecting to virtuos

Re: [Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

2013-05-27 Thread Sebastian Trüg
On 05/26/2013 12:58 AM, Vishesh Handa wrote: Hey guys I have made a very important discovery - The Storage service is a big bottleneck! Running a query such as - 'select * where { graph ?g { ?r ?p ?o. } } LIMIT 5' by directly connecting to virtuoso via ODBC takes about 2.65 seconds. In cont

Re: [Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

2013-05-26 Thread Vishesh Handa
On Sun, May 26, 2013 at 6:19 PM, Volker Krause wrote: > There are some general reasons for the extra server process: > - abstracting the database backend, hardly any of them are actually > compatible > on the SQL level, and if they are you still might want specific > optimizations. > Couldn't th

Re: [Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

2013-05-26 Thread Christian Mollekopf
On Sunday 26 May 2013 14.49:25 Volker Krause wrote: > On Sunday 26 May 2013 13:23:14 Christian Mollekopf wrote: > > On Sunday 26 May 2013 04.28:01 Vishesh Handa wrote: > > > Hey guys > > > > > > I have made a very important discovery - The Storage service is a big > > > bottleneck! > > > > > > Ru

Re: [Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

2013-05-26 Thread Volker Krause
On Sunday 26 May 2013 13:23:14 Christian Mollekopf wrote: > On Sunday 26 May 2013 04.28:01 Vishesh Handa wrote: > > Hey guys > > > > I have made a very important discovery - The Storage service is a big > > bottleneck! > > > > Running a query such as - 'select * where { graph ?g { ?r ?p ?o. } } L

Re: [Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

2013-05-26 Thread Christian Mollekopf
On Sunday 26 May 2013 04.28:01 Vishesh Handa wrote: > Hey guys > > I have made a very important discovery - The Storage service is a big > bottleneck! > > Running a query such as - 'select * where { graph ?g { ?r ?p ?o. } } LIMIT > 5' by directly connecting to virtuoso via ODBC takes about 2.

[Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

2013-05-25 Thread Vishesh Handa
Hey guys I have made a very important discovery - The Storage service is a big bottleneck! Running a query such as - 'select * where { graph ?g { ?r ?p ?o. } } LIMIT 5' by directly connecting to virtuoso via ODBC takes about 2.65 seconds. In contrast running the same query by using the Nepomu