On 25-2-2017 19:36, Dmitry Yemanov wrote:
>> From the perspective of JDBC the statement query timeout is to be
>> applied to the execute, and optionally for result set method calls. The
>> wording in the specification is a bit vague, but the expectation is that
>> the timeout is applied to each met
On 25-2-2017 20:20, Vlad Khorsun wrote:
> 25.02.2017 13:03, Mark Rotteveel wrote:
>> As a client of a database, I want to make progress with my work, which
>> means that processing rows is making progress, while waiting for an
>> execute or a fetch of rows is not making progress.
>
>So, waiting
I believe that the functionality is implemented correctly. In terms of
engine SQL statement must be completed to stop the timer, if it is a
select query to include fetches of all records. This is in good agreement
with the new strategy for the garbage collection READ COMMITTED
transactions,
26.02.2017 11:55, Simonov Denis wrote:
> In terms of
> engine SQL statement must be completed to stop the timer, if it is a
> select query to include fetches of all records.
Shouldn't this timer run till call isc_free_statement(..., DSQL_close)
instead of fetch
of the last record? Bidirection
Dimitry Sibiryakov wrote Sun, 26 Feb 2017 14:16:53
+0300:
>
>Shouldn't this timer run till call isc_free_statement(...,
> DSQL_close) instead of fetch
> of the last record? Bidirectional cursors will still keep resources
> after last fetch and
> current timeout won't help to free them.
26.02.2017 12:39, Simonov Denis wrote:
> However, bidirectional cursors are still not supported on the
> client side.
Yes. But still a new feature must be made with taking into account not only
current
features but future ones as well. Otherwise it could block development of them
or will
ha
> > 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.
I have no problem with "ExecutionQuota" describing the functionality that I am
referring to
Dmitry,
> That said, I'd vote against reworking the current design. Perhaps, we could
> additionally implement what Sean suggests, but *only* at the server side.
I expected that the "ExecutionQuota" would be something only executed at the
server side, since that is the only place where the appro
>Sure. And it is stated in docs at first place:
>
> ---
>The feature could be useful for:
> - database administrators get instrument to limit heavy queries from
>consuming too much resources
The problem is that long running transactions does not always equate to "heavy
qu
> > ---
> >The feature could be useful for:
> > - database administrators get instrument to limit heavy queries from
> >consuming too much resources
>
> The problem is that long running transactions does not always equate to
> "heavy queries".
>
> (1) A NATURAL SELECT which re
25.02.2017 21:40, Jiří Činčura wrote:
> 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 (alth
11 matches
Mail list logo
