On Tue, Jul 25, 2006 at 10:02:16PM +0200, Arjen P. de Vries wrote:
Wasn't the property checking always determined by debug flag 8?
in general: yes. for join: no, at least not any more since the following checkin: =================================================================== 2003/08/06 - sjoerd: src/gdk/gdk_relop.mx,1.38 DDI Merge.
This is the big one!
Before tag: BeforeDDImerge, after tag: AfterDDImerge.
The DDI merge is now made the official main branch; the CWI_DDI_merge branch is not to be used anymore. ===================================================================
Well, Sjoerd just did the checking; the origin is most probabaly Peter. As I said, there are indeed good reasons to do the BATpropcheck (even with debug=0) for *arbitrary* joins, where we can hardly predict any result properties --- maybe, we should consider to not do it in those cases (especially fetchjoin), where we can predict the join result properties pretty well...
Stefan
On 25/07/06, Martin Kersten Martin.Kersten@cwi.nl wrote:
Stefan Manegold wrote:
Dear all,
- We should consider making this BATpropcheck in BATjoin and BATleftjoin configurable from the outside, e.g., by adding an extra optional
argument
to join() to request to skipping the BATpropcheck.
Instead of pollution of the calling interface, I think we should inject an explicit request to check/enforce properties. This one might also be focussed on those properties of interest according to the optimizer at that point.
In M5: b:= algebra.join(BAT,BAT); bat.setProperties(b);
... bat.checkDenseProperty(b); bat.checkOrderProperty(b); bat.checkKeyProperty(b);
But first, assess the use of the join(bat,bat) in our controlled code base. Please report on this.
regards, Martin
--
CWI, room C1.16 Centre for Mathematics and Computer Science Kruislaan 413 Email: Arjen.de.Vries@cwi.nl 1098 SJ Amsterdam tel: +31-(0)20-5924306 The Netherlands fax: +31-(0)20-5924312 ===================== http://www.cwi.nl/~arjen/ ====================