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