Hi,
I'm currently writing my bachelor's thesis at the university of Konstanz about extending BaseX [1] with XQuery Update. I wanted to compare evaluation times between MonetDB and BaseX, as they have comparable table layouts, but am facing several problems.
So far I read your manual that suggests to use functions to support caching, as well as limiting inserts to a single position in a document. Some papers provided insight too [2,3], still there are questions (hopefully I didn't miss anything on your mailing lists and I hit the right one):
1. General storage: In which way is free space reserved, if an updatable document via fn:add-doc(u, x, y, freeSpace) is added? Let's assume freeSpace = 10%. Does this mean that free space (equal to 10% of our document size) is allocated between all used pages on disk? Spoken clearly, one tenth of free space on every page? But this would be in conflict with the suggestion to limit inserts to a single position in a document...
2. Timing: What happens during the 'Print'...ing part when I use the '-t' flag for timings? Query time is amazingly fast, yet I experience unusually long printing times - even for a small test document. Increasing the free space variable (see question 1) results in even longer printing times, which is on one side perfectly understandable as more pages on disk are used (right?)...
3. Yet, on the other side empty space on disk should not be accessed? I expect there to be a balance between query performance and free space? Is there a rule of thumb I can apply to get the most out of MonetDB (regarding specific queries of course)?
4. Are there any general advises for testing update performance of MonetDB?
I could gain some knowledge from a previous post on the developers list - yet I feel it's not enough to explain the results of my (yet immature) tests and to do your system justice ...
Thanks for your help! Looking forward to your answer...
Best regards, Lukas
[1] www.basex.org [2] Updating the Pre/Post Plane in MonetDB/XQuery [3] MonetDB/XQuery: A Fast XQuery Processor Powered by a Relational Engine