{"issue":{"milestone":null,"title":"[LDB-138] filtering returns incorrect count using 1M row table","created_at":"2011-12-30T02:19:33Z","user":{"login":"dynamobi-build","id":1123017,"url":"https://api.github.com/users/dynamobi-build","avatar_url":"https://secure.gravatar.com/avatar/cb215b3d786be20761071a562a56af64?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"cb215b3d786be20761071a562a56af64"},"labels":[{"name":"LDB","url":"https://api.github.com/repos/dynamobi/dynamobi/labels/LDB","color":"e2b9bd"}],"updated_at":"2011-12-30T02:19:39Z","state":"closed","id":2685356,"closed_at":"2011-12-30T02:19:34Z","html_url":"https://github.com/dynamobi/dynamobi/issues/183","pull_request":{"patch_url":null,"html_url":null,"diff_url":null},"body":"<b><i>[reporter=\"schoi\", created=\"Tue, 12 Sep 2006 12:36:15 -0500 (GMT-05:00)\"]</i></b>\nTo repro:<br/>\n--------------<br/>\n/open/luciddb/test/sql/sqbm$  ant test -Dbh.test-names=sqbm.sqbm2b<br/>\n<br/>\nIt takes approx 4.5 minutes to run (load and multiple select count(*) from a 1 million row table)<br/>\n<br/>\nFails at this query:<br/>\nselect count(*) from bench1m where k2 = 2 and not (K1K = 3);<br/>\n<br/>\n-- returns:<br/>\n+---------+<br/>\n| EXPR$0  |<br/>\n+---------+<br/>\n| 499897  |<br/>\n+---------+<br/>\n<br/>\n-- expecting<br/>\n+---------+<br/>\n| EXPR$0  |<br/>\n+---------+<br/>\n| 499901  |<br/>\n+---------+<br/>\n<br/>\nNote that I just updated the ref file .. the correct return should be 499901. (checked against excel)  Before, when this test was \"passing\", it was returning 499900.","number":183,"url":"https://api.github.com/repos/dynamobi/dynamobi/issues/183","comments":3,"assignee":null},"comment":{"created_at":"2011-12-30T02:19:39Z","user":{"login":"dynamobi-build","id":1123017,"url":"https://api.github.com/users/dynamobi-build","avatar_url":"https://secure.gravatar.com/avatar/cb215b3d786be20761071a562a56af64?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"cb215b3d786be20761071a562a56af64"},"updated_at":"2011-12-30T02:19:39Z","id":3308905,"body":"<b><i>[author=\"zfong\", created=\"Wed, 13 Sep 2006 11:09:31 -0500 (GMT-05:00)\"]</i></b>\nUpon further investigation, it now looks like this may be a mergeEntry problem!  Expanding on what I did in the previous comment, I was able to track down that it appears to be the index search that is first losing one of the missing rids (360427).  In my new table, k2res, that rid value corresponds to the row with lcs_rid = 180430.  Tracing the index values stored in the index that's on k2res(k1k), shows that rid value 180430 is completely missing from that btree.<br/>\n<br/>\nSo far, I've traced LbmGeneratorExecStream and LbmSplicerExecStream.  Generator is generating a bitmap entry with rid 180430, but splicer is not.  I suspect there may be a problem in mergeEntry handling a corner case because the missing rid (180430) is at the very end of the first entry to be spliced, and the next entry that it's being spliced with is a singleton with rid value 184230.  From the splicer trace, it looks like the attempt to splice in 184230 runs out of space, and mergeEntry decides to produce the first entry.  But when it does, it loses the last rid in the entry.  I need to debug further to confirm this.<br/>\n<br/>\nI'm guessing this behavior is now showing up because of the changes I made for the resource governor.  With the new resource governor, generator is getting allocated more scratch pages.  With more scratch pages, generator is likely generating bigger entries, which changes the entries that end up getting spliced. ","url":"https://api.github.com/repos/dynamobi/dynamobi/issues/comments/3308905"},"action":"created"}