You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I ran a select with group by on a big table without indexes to force an in-memory sort.
I was expecting to see the reported memory used by the statement to increase (up to ~64MB, limited by TempCacheLimit).
Instead, the database memory (stat_group=0) reports a significant increase (as expected) from 35MB to 90MB. But statement, transaction and attachment memory remains very low somewhere between 2 and 60KB (note it's KB not MB).
There is no direct way of detecting which statement, transaction or attachment is actually consuming that big block of memory.
IMO, the reported statement memory should include every bit that was allocated specifically for that statement.
Submitted by: Douglas Tosi (douglasht)
I ran a select with group by on a big table without indexes to force an in-memory sort.
I was expecting to see the reported memory used by the statement to increase (up to ~64MB, limited by TempCacheLimit).
Instead, the database memory (stat_group=0) reports a significant increase (as expected) from 35MB to 90MB. But statement, transaction and attachment memory remains very low somewhere between 2 and 60KB (note it's KB not MB).
There is no direct way of detecting which statement, transaction or attachment is actually consuming that big block of memory.
IMO, the reported statement memory should include every bit that was allocated specifically for that statement.
The complete discussion thread is here:
http://sourceforge.net/mailarchive/forum.php?thread_name=gvets3%24g9d%241%40news.atkin.com&forum_name=firebird-devel
Commits: 8e36474
The text was updated successfully, but these errors were encountered: