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