Sergi, I really want those 20% of performance :)
Can we just cache the parsed query based on the query string that is passed in? If not, can you think of another way to do it, without changing the API? If not, can we change the API and still keep its backward-compatibility, like we do with QueryEntity configuration? D. On Wed, Nov 4, 2015 at 7:00 AM, Sergi Vladykin <[email protected]> wrote: > Yes, it is a problem and I believe after distributed joins feature will be > merged, it will become even worse. > > Though I'd prefer to avoid changing public API for now. I believe it must > be enough to cache > and reuse parsed query information, generated queries and other stuff. > > Sergi > > 2015-11-04 16:43 GMT+03:00 Vladimir Ozerov <[email protected]>: > > > Igniters, > > > > Currently I'm profiling query execution on a single node on a realtively > > small data set (100K entries). What I see is that query parsing consumes > > about 20% of all execution time. > > > > Do we have something like JDBC PreparedStatement for our queries to > > minimize this overhead? If no, does it make sense to have it? > > > > Vladimir. > > >
