On Mon, Oct 16, 2017 at 12:15 AM, Vladimir Ozerov
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
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
On Sun, Oct 15, 2017 at 12:27 AM, Vladimir Ozerov
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?
No, it is not exposed to public API. Didn't want to add another flag to
SqlFieldsQuery.
вс, 15 окт. 2017 г. в 0:19, Dmitriy Setrakyan :
> 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
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
wrote:
> Dmitry,
>
> Corretct. Example: jdbc:ignite:thin://192.168.0.1?skipReducerOnClient=true
>
> On Fri, Oct 13, 2017 at 8:16 PM, Dmitriy
Dmitry,
Corretct. Example: jdbc:ignite:thin://192.168.0.1?skipReducerOnClient=true
On Fri, Oct 13, 2017 at 8:16 PM, Dmitriy Setrakyan
wrote:
> Vova,
>
> Just to make sure, we are not adding a new configuration property, right?
> Is this just a JDBC connection flag we are
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 wrote:
> Vladimir,
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
Vladimir, I think serverSideDml is better.
--Yakov
Or "skipReducerOnUpdate"
On Fri, Oct 13, 2017 at 10:05 AM, Vladimir Ozerov
wrote:
> Guys,
>
> I think I have a little bit better candidate: "bypassReducerOnUpdate".
>
> On Fri, Oct 13, 2017 at 10:03 AM, Vladimir Ozerov
> wrote:
>
>> Dima,
>>
>> Yes,
Guys,
I think I have a little bit better candidate: "bypassReducerOnUpdate".
On Fri, Oct 13, 2017 at 10:03 AM, Vladimir Ozerov
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
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
wrote:
> On Wed, Oct 11, 2017 at 11:45 PM, Vladimir Ozerov
> 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
On Wed, Oct 11, 2017 at 11:45 PM, Vladimir Ozerov
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.
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
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
wrote:
> Igniters,
>
> We
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
17 matches
Mail list logo