Vova, is there any way to enable this flag from API, without using JDBC
driver?

On Sat, Oct 14, 2017 at 1:17 PM, Vladimir Ozerov <voze...@gridgain.com>
wrote:

> Dmitry,
>
> Corretct. Example: jdbc:ignite:thin://192.168.0.1?skipReducerOnClient=true
>
> On Fri, Oct 13, 2017 at 8:16 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
> wrote:
>
> > Vova,
> >
> > Just to make sure, we are not adding a new configuration property, right?
> > Is this just a JDBC connection flag we are discussing? If yes, can you
> > please provide an example of the JDBC connection string?
> >
> > D.
> >
> > On Fri, Oct 13, 2017 at 9:57 AM, Denis Magda <dma...@apache.org> wrote:
> >
> > > Vladimir,
> > >
> > > > "inPlaceUpdate" is not very good candidate because there are a lot of
> > > other
> > > > "in place update" optimizations in RDBMS word, and most of them
> relates
> > > to
> > > > in-place update of some value in the data page. I am afraid users
> will
> > be
> > > > confused with this name.
> > >
> > > I’m not insisting on this name but that’s neither system nor global
> > > configuration property. The property scope is defined by the drivers’s
> > > boundaries. So if to think of it as of a hint for the drivers it
> doesn’t
> > > sound too generic.
> > >
> > > Anyway, “reducer” versions sound too low-level and, probably, I would
> > > leave the current “updateOnServer” as is.
> > >
> > > —
> > > Denis
> > >
> > > > On Oct 13, 2017, at 12:02 AM, Vladimir Ozerov <voze...@gridgain.com>
> > > wrote:
> > > >
> > > > Denis,
> > > >
> > > > In future SQL transactional protocol will do all updates "in place"
> > > instead
> > > > of passing it to the client. This is the only possible way to perform
> > > large
> > > > updates without killing the client with OOME.
> > > > "inPlaceUpdate" is not very good candidate because there are a lot of
> > > other
> > > > "in place update" optimizations in RDBMS word, and most of them
> relates
> > > to
> > > > in-place update of some value in the data page. I am afraid users
> will
> > be
> > > > confused with this name.
> > > >
> > > > On Fri, Oct 13, 2017 at 2:15 AM, Denis Magda <dma...@apache.org>
> > wrote:
> > > >
> > > >> How about “inPlaceUpdate”?
> > > >>
> > > >> A side note, I see the feature documented for ODBC in our hidden SQL
> > > >> domain [1]. But it’s missing for JDBC. Did we forget to update the
> > JDBC
> > > >> docs?
> > > >>
> > > >> [1] https://apacheignite-sql.readme.io/docs/connection-
> > > >> string-and-dsn#section-supported-arguments
> > > >>
> > > >>>
> > > >>> Unfortunately we cannot enable this mode by default, because it is
> > > still
> > > >> a
> > > >>> bit raw and there is a risk of regressions. Also when transactional
> > SQL
> > > >> is
> > > >>> ready this feature will make no sense in TX mode. For this reason
> we
> > > >>> disable it by default for now
> > > >>
> > > >>
> > > >> Does it mean that this kind of optimization is not feasible for
> > > >> transaction SQL or it will be just solved differently? Just trying
> to
> > > grasp
> > > >> if we are going to drop it after the TX SQL release.
> > > >>
> > > >> —
> > > >> Denis
> > > >>
> > > >>> On Oct 11, 2017, at 11:45 PM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > >> wrote:
> > > >>>
> > > >>> Igniters,
> > > >>>
> > > >>> We prepared optimization of DML processing. Instead of passing all
> > data
> > > >>> being updated through the client node, now we can optionally send
> SQL
> > > >>> statement to data nodes and perform update locally. This could
> > greatly
> > > >>> improve performance of certain DML operations.
> > > >>>
> > > >>> Unfortunately we cannot enable this mode by default, because it is
> > > still
> > > >> a
> > > >>> bit raw and there is a risk of regressions. Also when transactional
> > SQL
> > > >> is
> > > >>> ready this feature will make no sense in TX mode. For this reason
> we
> > > >>> disable it by default for now.
> > > >>>
> > > >>> It will be possible to enable it from JDBC/ODBC drivers using a
> flag.
> > > >>> Question - how to name this flag? Current name is
> > "*updateOnServer*". I
> > > >>> doesn't like it much, but cannot do better. Please share other
> ideas.
> > > >>>
> > > >>> - "distributedDml"? No, every operation is distributed.
> > > >>> - "serverDml"?
> > > >>>
> > > >>> Vladimir.
> > > >>
> > > >>
> > >
> > >
> >
>

Reply via email to