[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user cramja commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 @jianqiao thanks! will close. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature

[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user jianqiao commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 @pateljm The PR was merged but was not closed automatically, @cramja can manually close it. --- If your project is set up for it, you can reply to this email and have your reply

[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user jianqiao commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 Merged and closed. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled

[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user jianqiao commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 @cramja I'm not sure about the overhead for calling the constructor inside the accessor loop. We can first have this `setMemory()` version merged to have a reference for the

[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user cramja commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 @jianqiao Sure, that sounds good. @navsan and I talked about another alternative which is to call the BitVector constructor instead of `setMemory`. I made the `set` method because I

[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user cramja commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 If that's what were waiting on, then yes, I can go test it. Of course that will be with a subset of working queries. --- If your project is set up for it, you can reply to this email

[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user cramja commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 @hbdeshmukh I updated for TPCH in the PR header --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not

[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user cramja commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 Thanks @hakanmemisoglu I tried something similar to what you were suggesting and the "works but I don't know why" solution I found was to declare the variables inside the lambda. It's

[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user cramja commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 @hbdeshmukh 2x improvement was for the contrived test of trying to insert a whole bunch of tuples into a Splitrow at once as in PR100. As for TPCH, I'm not sure, other than that this is

[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user navsan commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 This bug was filed and fixed a year ago in 5.3, I think. It had been around for 2-3 years, so we’ll probably be affected in older versions of GCC too.

[GitHub] incubator-quickstep issue #109: Refactored SplitRowStore bulk insertion

Github user hakanmemisoglu commented on the issue: https://github.com/apache/incubator-quickstep/pull/109 Hi @cramja, the problem might be related lambda capture arguments. GCC 5 was giving the same problems if you use general capture by reference [&]. You can try to give specific