You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Vladimir Ozerov <vo...@gridgain.com> on 2017/10/12 06:45:17 UTC
Optimized DML execution: how to name it?
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.
Re: Optimized DML execution: how to name it?
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Oct 16, 2017 at 12:15 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> Dmitriy,
>
> No :-) System properties is bad practice, because in some cases you cannot
> change them. Instead, this flag is available in private class
> SqlFIeldsQueryEx. So in case user desperately need it, we may advise him to
> use this class. But I hope it will not be needed.
>
Disagree. This is a temporary property and there is no reason to expose
users to external APIs. System property is the easiest to get rid of in the
future.
Re: Optimized DML execution: how to name it?
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Dmitriy,
No :-) System properties is bad practice, because in some cases you cannot
change them. Instead, this flag is available in private class
SqlFIeldsQueryEx. So in case user desperately need it, we may advise him to
use this class. But I hope it will not be needed.
On Sun, Oct 15, 2017 at 5:09 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Sun, Oct 15, 2017 at 12:27 AM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
> > No, it is not exposed to public API. Didn't want to add another flag to
> > SqlFieldsQuery.
> >
>
> I think we should add a system property. This way you don't have to add any
> API flags. Agree?
>
Re: Optimized DML execution: how to name it?
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Sun, Oct 15, 2017 at 12:27 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> No, it is not exposed to public API. Didn't want to add another flag to
> SqlFieldsQuery.
>
I think we should add a system property. This way you don't have to add any
API flags. Agree?
Re: Optimized DML execution: how to name it?
Posted by Vladimir Ozerov <vo...@gridgain.com>.
No, it is not exposed to public API. Didn't want to add another flag to
SqlFieldsQuery.
вс, 15 окт. 2017 г. в 0:19, Dmitriy Setrakyan <ds...@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 <vo...@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 <dm...@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 <dm...@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.
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Optimized DML execution: how to name it?
Posted by Dmitriy Setrakyan <ds...@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 <vo...@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 <ds...@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 <dm...@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 <vo...@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 <dm...@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.
> > > >>
> > > >>
> > >
> > >
> >
>
Re: Optimized DML execution: how to name it?
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Dmitry,
Corretct. Example: jdbc:ignite:thin://192.168.0.1?skipReducerOnClient=true
On Fri, Oct 13, 2017 at 8:16 PM, Dmitriy Setrakyan <ds...@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 <dm...@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 <vo...@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 <dm...@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 <vo...@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.
> > >>
> > >>
> >
> >
>
Re: Optimized DML execution: how to name it?
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <dm...@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 <vo...@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 <dm...@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 <vo...@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.
> >>
> >>
>
>
Re: Optimized DML execution: how to name it?
Posted by Denis Magda <dm...@apache.org>.
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 <vo...@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 <dm...@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 <vo...@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.
>>
>>
Re: Optimized DML execution: how to name it?
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <dm...@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 <vo...@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.
>
>
Re: Optimized DML execution: how to name it?
Posted by Denis Magda <dm...@apache.org>.
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 <vo...@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.
Re: Optimized DML execution: how to name it?
Posted by Yakov Zhdanov <yz...@apache.org>.
Vladimir, I think serverSideDml is better.
--Yakov
Re: Optimized DML execution: how to name it?
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Or "skipReducerOnUpdate"
On Fri, Oct 13, 2017 at 10:05 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> Guys,
>
> I think I have a little bit better candidate: "bypassReducerOnUpdate".
>
> On Fri, Oct 13, 2017 at 10:03 AM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
>> Dima,
>>
>> Yes, in future releases we will enable it by default. New TX protocol
>> will work in pretty much the same way.
>>
>> On Fri, Oct 13, 2017 at 4:57 AM, Dmitriy Setrakyan <dsetrakyan@apache.org
>> > wrote:
>>
>>> On Wed, Oct 11, 2017 at 11:45 PM, Vladimir Ozerov <vo...@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.
>>>
>>>
>>> This feature should be enabled by default, as it should not be up to a
>>> user
>>> to decide when to use it. Whatever name we come up with now will be
>>> temporary, so it does not really matter.
>>>
>>> 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.
>>> >
>>>
>>> We should figure out a proper way to use it in transactional mode. I am
>>> sure we can, once we think it through. But even if we cannot, the system
>>> should automatically decide when to use this optimization and when not to
>>> use it.
>>>
>>>
>>> >
>>> > 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"?
>>> >
>>>
>>> In my view, we should come up with a generic enable/disable switch for
>>> all
>>> experimental features. For example,
>>> "experimental=feature1,feature2,feature3". Then, once a feature stops
>>> being
>>> experimental, we simply enable it in the system via normal Ignite
>>> configuration or by default.
>>>
>>
>>
>
Re: Optimized DML execution: how to name it?
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Guys,
I think I have a little bit better candidate: "bypassReducerOnUpdate".
On Fri, Oct 13, 2017 at 10:03 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> Dima,
>
> Yes, in future releases we will enable it by default. New TX protocol will
> work in pretty much the same way.
>
> On Fri, Oct 13, 2017 at 4:57 AM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
>> On Wed, Oct 11, 2017 at 11:45 PM, Vladimir Ozerov <vo...@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.
>>
>>
>> This feature should be enabled by default, as it should not be up to a
>> user
>> to decide when to use it. Whatever name we come up with now will be
>> temporary, so it does not really matter.
>>
>> 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.
>> >
>>
>> We should figure out a proper way to use it in transactional mode. I am
>> sure we can, once we think it through. But even if we cannot, the system
>> should automatically decide when to use this optimization and when not to
>> use it.
>>
>>
>> >
>> > 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"?
>> >
>>
>> In my view, we should come up with a generic enable/disable switch for all
>> experimental features. For example,
>> "experimental=feature1,feature2,feature3". Then, once a feature stops
>> being
>> experimental, we simply enable it in the system via normal Ignite
>> configuration or by default.
>>
>
>
Re: Optimized DML execution: how to name it?
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Dima,
Yes, in future releases we will enable it by default. New TX protocol will
work in pretty much the same way.
On Fri, Oct 13, 2017 at 4:57 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Wed, Oct 11, 2017 at 11:45 PM, Vladimir Ozerov <vo...@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.
>
>
> This feature should be enabled by default, as it should not be up to a user
> to decide when to use it. Whatever name we come up with now will be
> temporary, so it does not really matter.
>
> 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.
> >
>
> We should figure out a proper way to use it in transactional mode. I am
> sure we can, once we think it through. But even if we cannot, the system
> should automatically decide when to use this optimization and when not to
> use it.
>
>
> >
> > 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"?
> >
>
> In my view, we should come up with a generic enable/disable switch for all
> experimental features. For example,
> "experimental=feature1,feature2,feature3". Then, once a feature stops
> being
> experimental, we simply enable it in the system via normal Ignite
> configuration or by default.
>
Re: Optimized DML execution: how to name it?
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Wed, Oct 11, 2017 at 11:45 PM, Vladimir Ozerov <vo...@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.
This feature should be enabled by default, as it should not be up to a user
to decide when to use it. Whatever name we come up with now will be
temporary, so it does not really matter.
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.
>
We should figure out a proper way to use it in transactional mode. I am
sure we can, once we think it through. But even if we cannot, the system
should automatically decide when to use this optimization and when not to
use it.
>
> 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"?
>
In my view, we should come up with a generic enable/disable switch for all
experimental features. For example,
"experimental=feature1,feature2,feature3". Then, once a feature stops being
experimental, we simply enable it in the system via normal Ignite
configuration or by default.
Re: Optimized DML execution: how to name it?
Posted by Igor Sapego <is...@apache.org>.
Here is the link for the ticket [1] If someone else was wandering
about what kind of optimization we are talking.
[1] - https://issues.apache.org/jira/browse/IGNITE-6024
Best Regards,
Igor
On Thu, Oct 12, 2017 at 9:45 AM, Vladimir Ozerov <vo...@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.
>