> Brian Kelley wrote: > > The memory usage of individual deletes, especially across blocked > views, is most probably due to MK allocating 4 Kb buffer chunks in > every column a change is made (and sometimes much more to hold > modified copies of ranges of data). With blocked views, I suspect > that memory usage could indeed rise to a multiple of the dataset. > A blocked view with say 5 columns and 40000 rows, could have 5 x 40 > = 200 blocks, i.e. 800 Kb of sparsely filled buffers pending until > flushed by a commit or rollback. > > The fix for this would be to track the total set of buffers, and > start coalescing some in-memory data buffers to free some of that > up (and to do so well before actual commits). > > I'm surprised that memory usage stays high across commits though, > and even more by what looks like a 32-bit sign overflow in file > positions getting through undetected and messing up a datafile. > The 2 Gb limit should lead to commit failures, not file damage!
I'm not sure that this was a memory issue, the metakit file itself was growing to 2+ gig, so it seems that in the way I was deleting from the blocked views rapidly grew the database. I'll spend some time today making an example database and doing the individual commits in case you want to test the issue.
Brian
_____________________________________________ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
