I feel like I'm missing something, but that didn't seem to help. I can see in the code why it should be behaving differently (many thanks for the hint on where to look, BTW), but the memory usage is unchanged.
I modified sqliteInt.h to define SQLITE_OMIT_MEMORYDB, then verified that it is defined by: a) inserting garbage into vdbeaux.c to prevent it from compiling when SQLITE_OMIT_MEMORYDB is defined b) tried to attach to database :memory: without success (it created a file name :memory: instead), and c) started the command line tool without specifying a database and noting that the main database is a file named $CD/:memory: Am I missing something stupid here? Or is all my memory being used somewhere other than constructing the b-tree used for aggregation? Thanks -Tom > -----Original Message----- > From: D. Richard Hipp [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 24, 2005 11:19 AM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] Memory usage for queries containing a > GROUP BY clause > > On Thu, 2005-03-24 at 10:57 -0500, Thomas Briggs wrote: > > After posting my question, I found the discussion of how > aggregate > > operations are performed in the VDBE Tutorial; that implies > that memory > > usage will correspond with the number of unique keys > encountered by the > > query, but I appreciate having it stated explicitly. > > > > How difficult would it be, in concept, to change the > storage of the > > hash buckets from in-memory to on-disk? The VDBE Tutorial makes it > > sound like it would be a matter of changing the AggFocus, > AggNext, and > > maybe a few other operations to store/retrieve buckets from > disk before > > operating on them in memory. How dramatically am I oversimplifying > > this? :) > > > > You have the right idea. But the job is really much easier. All of > the Agg* opcodes already use the standard btree mechanism for storing > and retrieving their buckets. But they use a ":memory:" btree by > default. > To make it use disk, all you have to do is get it to store > the btree in > a temporary file on disk. > > One easy way to make this happen is to recompile with > -DSQLITE_OMIT_MEMORYDB. > See source file vdbeaux.c near line 800 for additional information. > If you want to hack together a customized version of SQLite that > behaves differently, that would be a good place to start. > -- > D. Richard Hipp <[EMAIL PROTECTED]> > >
