Johann Borck wrote:
Fabian Groffen wrote:
Ok, but in this situation, it looks to me as if you would benefit from a "real" embedded version of MonetDB, where you just talk to a library instead, omitting all costs of Mapi/TCP and simply stick to method calls.
Is this what's mentioned in the docs/examples as embedded mode, or even lower level? I thought about using it embedded, but what scared me a bit is that locking is turned of completely when using it this way, and so big transactions could make smaller ones wait. OTOH real big transactions are not very probable for my usecase and the embedded version is probably very very fast :). Indeed the embedded version was originally carved out to run on a SBC Linux board of an MP3 player. Transactions came from a single user. Concurrency control overhead could raise to >30% of all cpu cycles.
If your usecase has the option to differentiate short/long transactions then you might consider a queuing scheme, postponing the long ones. Or, alternatively, break the long one semantically into independent pieces. If your database fits in memory, I would definitely look at serial execution as the way to go and counter overload by an admission policy. Martin
Is asynchronous equal to non-blocking IO in your case? The latter one should be too hard, I suppose...
Yep, it implies non-blocking IO. All right.. I think first I should see how the embedded stuff works out. thanks for the suggestion, Johann
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers