On Fri, Sep 14, 2012 at 3:44 AM, Maya Opperman wrote:
>
> > I'd like both reads and fetches, with statistics
> >for a run of the subquery that's fast and one that's slow. Did you mean
> >that computing one account balance involved forty-seven thousand indexed
> >reads? That's some account!
>
>
Attributes force write, no reserve
>>> Having "no reserve" isn't a good option for a regular read/write production
>>> database, because this basically prevents having back record versions on
>>> the same page as the primary record version, thus additional page reads
>>> Attributes force write, no reserve
>
>> Having "no reserve" isn't a good option for a regular read/write production
>> database, because this basically prevents having back record versions on the
>> same page as the primary record version, thus additional page reads are
>> Attributes force write, no reserve
>Having "no reserve" isn't a good option for a regular read/write production
>database, because this basically prevents having back record versions on the
>same page as the primary record version, thus additional page reads are
>necess
Get the statistics on the various runs of the sub-procedure- reads,
>>> writes, fetches, and marks.
>>> No writes. 47 000 indexed reads.
>
>
>> Lets try that one again. I'd like both reads and fetches, with statistics
>> for a run of the subquery that's fast and one that's slow. Did you mea
>> >Get the statistics on the various runs of the sub-procedure- reads,
>> writes, fetches, and marks.
>> No writes. 47 000 indexed reads.
>Lets try that one again. I'd like both reads and fetches, with statistics
>for a run of the subquery that's fast and one that's slow. Did you mean
>that c
On Thu, Sep 13, 2012 at 9:50 AM, Maya Opperman wrote:
>
> >Get the statistics on the various runs of the sub-procedure- reads,
> writes, fetches, and marks.
> No writes. 47 000 indexed reads.
>
Lets try that one again. I'd like both reads and fetches, with statistics
for a run of the subquery th
>> If I run the sub proc to get the balance one by one though, it runs
>> at
>> 1-2 seconds. So, using IBExpert, I manually worked my way through
>> the list, and on the 5th account - 22 seconds to execute. I try the
>> very same account again, and it takes 1 seconds. I need to carry on
>> d
>> If I run the sub proc to get the balance one by one though, it runs at
>> 1-2 seconds. So, using IBExpert, I manually worked my way through the
>> list, and on the 5th account - 22 seconds to execute. I try the very
>> same account again, and it takes 1 seconds. I need to carry on down
>>
On Wed, Sep 12, 2012 at 3:06 AM, Maya Opperman wrote:
>
> >>I have a stored proc that calculates account balances. Most of the time
> it takes between 1-2 seconds, but every now and then it takes 22 seconds.
> It seems to be approx. every 5 or 6 records.
>
> >>If I run the sub proc to get the bal
>>I have a stored proc that calculates account balances. Most of the time it
>>takes between 1-2 seconds, but every now and then it takes 22 seconds.
>>It seems to be approx. every 5 or 6 records.
>>Ie. I have a stores procedure that returns a list of 6 accounts and their
>>balances.
>>I have
11 matches
Mail list logo
