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
> > ---
> >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
>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
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
> > 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
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
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 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
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,
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
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
11 matches
Mail list logo
