Subject | Re: [Firebird-Architect] Can we, can we, can we????... |
---|---|
Author | Miroslav Penchev |
Post date | 2005-06-14T18:38:31Z |
On Tue, 14 Jun 2005 14:32:07 -0400, Ann W. Harrison
<aharrison@...> wrote:
much more that 5 000 000 fetches (yes, they are slow, but they are much
faster that source code doing the same thing). I use such huge selects
generally for reporting purposes.
I think that such restriction (on fetches count) will be useless in 98% of
cases.
To me the best solution is to give in developer hands possibility to make
easy a Cancel button - that will solve all of the problems with long
queries or bad written queries.
Cheers,
--
Miroslav Penchev
<aharrison@...> wrote:
> Dmitry Yemanov wrote:I does not like the idea of counting fetches - I have a selects which made
>>>
>>> Elapsed time.
>>
>> Well, a direct compare doesn't suit our needs perfectly. A user who has
>> an
>> active grid with some not yet fetched rows will get a timeout error as
>> soon
>> as he press the "down" key. Perhaps it's better to track the time spent
>> in
>> the looper.
>
> Why not use the fetch count? Yes, I realize that the user doesn't know
> what a fetch is - nor does the user know what a trip through looper
> means. We already count fetches so there's no extra overhead. A bit of
> experimentation on our part could set up some guidelines - e.g. < 50000
> fetches is low, < 500000 fetches is moderate, < 5000000 fetches is high,
> other is unlimited.
>
much more that 5 000 000 fetches (yes, they are slow, but they are much
faster that source code doing the same thing). I use such huge selects
generally for reporting purposes.
I think that such restriction (on fetches count) will be useless in 98% of
cases.
To me the best solution is to give in developer hands possibility to make
easy a Cancel button - that will solve all of the problems with long
queries or bad written queries.
Cheers,
--
Miroslav Penchev