Lucky, I looks strange, that client driver works slower than thin. Normally it should work just like cache.query() + network overhead. Maybe you included connection time into your evaluation? Or something else? You should compare query execution time, when connection is already established and all preparatory work is done.
Can you share code of your benchmark? I'd like to make sure, that all measurements are correct. Denis вт, 5 дек. 2017 г. в 9:31, Lucky <[email protected]>: > Denis, > > This query just only retrieve 2 records. > As I say in the first message, cache.query() took less time. > > Another thing,I did a statistics. > When I enable enforceJoinOrder option, there are just few queries can > become faster , but more than 1000 queries become slower. > And I change the join order some queries, it happened nothing. > > Thanks. > > > > > > 在 2017-12-01 23:52:48，"Denis Mekhanikov" <[email protected]> 写道： > > Lucky, > > If you enable *enforceJoinOrder* option, then join operations will be > performed in the exact order, in which they appear in the query. This flag > prevents an SQL optimizer from rearranging the tables. > This is why some queries may become faster, and some slower. > > So, to find an optimal order, you can try rearranging tables in your > joins, i.e. changing *a JOIN b* to *b JOIN a*. > > Denis > > > пт, 1 дек. 2017 г. в 15:30, Denis Mekhanikov <[email protected]>: > >> Lucky, >> >> How much data do you retrieve in this query? >> There is some overhead, caused by network communication, when you are >> using JDBC drivers, but it's not expected to be so big. >> Also do you connect over JDBC to the same node, on which you test >> IgniteCache#query() ? >> >> Denis >> >> чт, 30 нояб. 2017 г. в 11:30, Lucky <[email protected]>: >> >>> Denis, >>> It's worse! >>> There just have several sql can be faster, the other took more time. >>> Thanks. >>> >>> >>>>
