ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Optimized DML execution: how to name it?
Date Fri, 13 Oct 2017 17:16:05 GMT
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