I'm going to look into this too but what I had in mind was some kind of maintenance you were running at one of your clients or something like that.
/Henrik On Tue, Jul 21, 2009 at 7:42 AM, Alexander Burger<a...@software-lab.de> wrot= e: > Hi Henrik, > >> I vaguely remember a discussion approaches to cleaning or optimizing >> databases, I searched the mailing list however without success. > > I'm not sure. There was a response (to some questions by Tomas) in > > =A0 http://www.mail-archive.com/picolisp@software-lab.de/msg00073.html > >> > What are the rules/heuristics for splitting entities and relations >> > into database files? >> >> As you perhaps know, you can specify database files and sizes with the >> 'dbs' function, which results in the initialization of the global >> variable '*Dbs'. You can see examples in "doc/family.l" and "app/er.l". >> >> As a minimum, I would recommend to separate objects and B-trees. Usually >> I experiment with the data model at the beginning of a project, and look >> at typical entity objects with 'size'. Then I specify a file for each >> size. >> >> The B-tree block sizes seem to be not very critical. A block is filled >> up dynamically anyway. It makes sense to put related indexes into the >> same file, or use a separate file for each index if the database is >> going to be big. I would put all small indexes together into a few >> files, and put each big index into its own file. >> >> At least for not too big databases, performance does not seem to depend >> very much on the block size. A value of 3 (block size 512 bytes) or 4 >> (1024) seems a good compromise. Only for very large databases (more than >> 10 million objects) I found that using very large blocks (6, resulting >> in 4096 bytes) improves performance. > > Was this what you had in mind? > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe > -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
