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. > > > >> > > > >> > > > > > > > > >