Hi, Alan, Looks like you have a pretty big data table. If you have also many column, then it is easy to run out of memory. There appears to be a gray zone between frequent malloc problems and smooth sailing. I suspect that this is where your error message is indicating. I don't believe there is a way for a user to switch to a different memory management algorithm yet. I will need to dig a little bit into the code in order to figure out what are the alternative options;-)
John On 2/2/17 1:28 AM, Alan Kemp wrote: > Hi John, > > Thanks very much for the response. > >> On 01 Feb 2017, at 6:48 PM, John Wu <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> The ibis::bord class is invoked most often for nested queries or more >> complex queries. My guess is that there are some intermediate results >> of a complex query or nested query that are a little too large for the >> memory on the given machine. Ideally, the software should try to >> limit its memory usage and switch to a slower algorithm rather than >> giving up with an incomprehensible error message;-) > > How can we switch to a slower algorithm ? And we do sometimes run into > memory issues, but then we get a malloc memory error. > >> You might not know how to reproduce the problem, but if you do, I'd be >> happy to debug the problem and see if I can implement a work-around. > > I can reproduce the problem any time š What do you need from me? > > There are 1 300 663 221 rows that Iām trying to query. > > Regards > > -- > *Alan Kemp* > Support: 0861 IRISNS (474767) or +27 21140 IRIS (4747) > Mobile: +27 83 257 5970 > *IRIS* Network Systems > > > > > > > > > _______________________________________________ > FastBit-users mailing list > [email protected] > https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users > _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
