OK, after reading the thread again and again, I think I'm starting to
understand what was Vlad shooting for. And I think his implementation
makes sense (so I'm fine moving it forward). This also makes sense
reading some of Vlad's scenarios in docs (although I see it more like
client-side only
25.02.2017 21:15, Jiří Činčura wrote:
>> But, client side already can set it own timer and cancel the statement.
>
> To add to what others said. Isn't this feature, also, about helping i.e.
> DBA to keep bad queries slowing down the server (considering (s)he has
> no control over the application's
> But, client side already can set it own timer and cancel the statement.
To add to what others said. Isn't this feature, also, about helping i.e.
DBA to keep bad queries slowing down the server (considering (s)he has
no control over the application's code itself)?
--
Mgr. Jiří Činčura
>But, client side already can set it own timer and cancel the statement.
At current time, you may forget about cancel of operation. Because it works
incorrectly.
Dmitry Kovalenko.
--
Check out the vibrant tech
25.02.2017 17:21, Adriano dos Santos Fernandes wrote:
>
> But, client side already can set it own timer and cancel the statement.
It was considered. However, it would mean that our implementation is
completely useless for Java and .NET clients, they would have to
implement timeouts from
Em 25/02/2017 08:03, Mark Rotteveel escreveu:
> On 25-2-2017 10:49, Dmitry Yemanov wrote:
>> Depending on the plan, statement may take 99% of its "working" time
>> inside execute() or inside fetch() or that time could be distributed
>> among the API calls. Neither client nor DBA has any control on
Em 25/02/2017 06:49, Dmitry Yemanov escreveu:
> So we have different requirements for the same feature and they conflict
> with each other. The positive side of the implemented solution is that
> it suits both client-side and server-side usage. Sean's suggestion does
> not fit client-side
On 25-2-2017 11:15, Dmitry Yemanov wrote:
> 25.02.2017 12:37, Mark Rotteveel wrote:
>
>>> Do you/anyone know if these engines return full results sets or follow the
>>> "page set" approach?
>>
>> As far as I know Oracle[1], PostgreSQL[2], SQL Server[3] support it. I
>> believe MySQL does as well.
On 25-2-2017 10:49, Dmitry Yemanov wrote:
> Depending on the plan, statement may take 99% of its "working" time
> inside execute() or inside fetch() or that time could be distributed
> among the API calls. Neither client nor DBA has any control on that. So
> I consider seriously wrong removing
25.02.2017 11:47, Mark Rotteveel wrote:
> On 25-2-2017 09:31, Vlad Khorsun wrote:
>>If think a bit deeper, it will be clear that there is no other way as
>> send big result sets
>> in parts over the wire. Also, why don't you ask if they fully fetch
>> resultset at the server side ?
>>
>>
25.02.2017 12:37, Mark Rotteveel wrote:
>> Do you/anyone know if these engines return full results sets or follow the
>> "page set" approach?
>
> As far as I know Oracle[1], PostgreSQL[2], SQL Server[3] support it. I
> believe MySQL does as well. Don't know about other database systems, but
> I
25.02.2017 10:49, Dmitry Yemanov wrote:
> Depending on the plan, statement may take 99% of its "working" time
> inside execute() or inside fetch() or that time could be distributed
> among the API calls. Neither client nor DBA has any control on that. So
> I consider seriously wrong removing
All,
Let me jump into discussion and share my own concerns.
Depending on the plan, statement may take 99% of its "working" time
inside execute() or inside fetch() or that time could be distributed
among the API calls. Neither client nor DBA has any control on that. So
I consider seriously
On 25-2-2017 01:55, Leyne, Sean wrote:
>>MSSQL implements timeouts at client side:
From a quick glance, in the ms-sql JDBC driver, the (client side) query
timeout is applied for waiting for a response from the server for an
execute, fetch, etc. Each action has its own the timeout timer, so
25.02.2017 03:55, Leyne, Sean wrote:
>
> it is the value that represent a direct CPU cost of a SQL statement.
You actually seem wanting CPU quotas. But they're not timeouts. A
long-running statement may produce almost zero CPU load.
Dmitry
On 25-2-2017 00:50, Vlad Khorsun wrote:
> 24.02.2017 20:14, Mark Rotteveel wrote:
> ...
>> It would be nice to know exactly what changes are involved in the wire
>> protocol for statement-specific timeouts without having to dive into the
>> implementation.
>
>Read, please, "Remote client
25.02.2017 2:55, Leyne, Sean wrote:
> Vlad,
>
> These connections perform only a few heavy weight SQL statements
(taking max 3-4 of real execution time).
> Most of the time is spent in the Firebird engine waiting for the
next fetch, due to network latencies.
In the
17 matches
Mail list logo
