"Ann W. Harrison" wrote:

> At 11:44 PM 2/10/2002 +0300, Lev Assinovsky wrote:
>
> >Each nested SELECT allocates approx 24K - which is never returned.
>
> This is probably incredibly obtuse (i.e. stupid) of me, but
> preparing a statement causes memory to be allocated in the
> server to hold the compiled version of the statement. The
> amount of memory is related to the record size of the table,
> the size of the data returned, and the complexity of the query.

In my case it depends on result set size from UPPER level select.
I know it sounds strange, but...
Thus if we have (select includes isc_dsql_prepare and isq_dsql_execute):

select tab1 //we expect memory allocation here, though
while (fecth tab1)
{
select tab2 // it happens here
while (fetch tab2)
{
}
}

select tab3
while (fecth tab3) // here we expect the reusing of memory
{
select tab4 // but memory allocates again
while (fetch tab4)
{
}
}

You are partially right. select tab4 allocates memory only if
tab3 has more columns then tab3. But the memory allocated in select tab1
IS NOT RELEASED!!

>
>
> The memory is released to the server when the request is
> released. Firebird/InterBase never return memory to the
> system on the assumption that some other connection will
> want to use memory and reusing allocated memory is cheaper
> than reallocating it.

You are talking about server. But memory grows on client side.

>
>
> Regards,
>
> Ann
> www.ibphoenix.com
> We have answers.
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Sincerely,

--
Lev Assinovsky Peterlink Web
Programmer St. Petersburg, Russia
Tel/Fax: +7 812 3275343 197022 ul.Chapigina 7а
E-mail: lev@...