Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGt6o8mopNZi1-fSnRorEsFpqsKs-Nr=Hx4sB86+fkTv9yB_aw@mail.gmail.com>
References: 
 <CAGt6o8kvne5B-StqL+FiO6D570Ee2zn-uF44-6Ns5_CA26BVzg@mail.gmail.com>
 <CA+eZwrF7bPRWJm2KxKOmGmjJc+hZF7dr_-Xm7pvSA4o4cOG16w@mail.gmail.com>
 <CAGt6o8mopNZi1-fSnRorEsFpqsKs-Nr=Hx4sB86+fkTv9yB_aw@mail.gmail.com>
From: Sergi Vladykin <sergi.vladykin@gmail.com>
Date: Thu, 5 Nov 2015 09:47:38 +0300
Message-ID: 
 <CA+eZwrGiUbk-GAcNtKHwfiwELG=EGB0QeNFhqSRFp3LRHg9BBg@mail.gmail.com>
Subject: Re: Prepared statement concept in indexing
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a114381a60dd5310523c5835c

--001a114381a60dd5310523c5835c
Content-Type: text/plain; charset=UTF-8

Ok, I've created jira issue and will try to put this into 1.5. release.

https://issues.apache.org/jira/browse/IGNITE-1856

Sergi

2015-11-04 21:17 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:

> Agree, it would be cool if we cache parsed queries without any changes to
> public API.
>
> But Dima, note that I saw this "20%" on local benchmark with only 1 node. I
> expect that in distributed environment it will be amortized by network.
>
> On Wed, Nov 4, 2015 at 6:00 PM, Sergi Vladykin <sergi.vladykin@gmail.com>
> 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 <vozerov@gridgain.com>:
> >
> > > 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.
> > >
> >
>

--001a114381a60dd5310523c5835c--