Re: [Monetdb-developers] [Monetdb-checkins] MonetDB/src/gdk gdk.mx, , 1.278, 1.279 gdk_bat.mx, , 1.213, 1.214 gdk_posix.mx, , 1.168, 1.169 gdk_relop.mx, , 1.161, 1.162 gdk_utils.mx, , 1.241, 1.242
Peter Boncz wrote: then we should also sort L on the tail oids first This under the constraint that sorting L also cost some IO If you are tweaking in that area anyway, such a patch is appreciated.
- disable vmalloc on Linux -- well actually on platforms that do not have posix_fadvise. A bit of a hack.
Martin, you suggest:
The problem is that many MonetDB use fetchjoin as an order-aware operator and expect the output to be in left input order. This is then exploited in tuple reconstruction. It will certainly break pathfinder, for instance. Applications like Proximity would also break. In my thesis, I had suggested to create an accelerator that attaches a radix-clustered version to the left input. Fetchjoin would then use this radix-clustered version, and call decluster on the result, restoring the original order (using a cache and dick-friendly pattern). However, I have come to dislike the idea of low-level accelerators. I now think this is better handled on a higher layer, specifically the relational algebra layer. Peter
participants (2)
-
Martin Kersten -
Peter Boncz