ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Optimized DML execution: how to name it?
Date Sun, 15 Oct 2017 07:27:02 GMT
No, it is not exposed to public API. Didn't want to add another flag to
SqlFieldsQuery.

вс, 15 окт. 2017 г. в 0:19, Dmitriy Setrakyan <dsetrakyan@apache.org>:

> 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 <vozerov@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 <
> dsetrakyan@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 <dmagda@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 <
> vozerov@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 <dmagda@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 <
> > vozerov@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.
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message