2014-08-07 0:30 GMT+04:00 Heikki Linnakangas <hlinnakan...@vmware.com>:
* I'm getting two regression failures with this (opr_sanity and join). > opr_sanity failure is corrected. But there is remain question with join. I check the latest version of my github repo and there's no fail in join regression test All 145 tests passed. To tell the truth, I don't understand which changes could led to this failure. Could you show me regression diffs? I want to understand what's wrong with the patch. * The regression test queries that use LIMIT are not guaranteed to always > return the same rows, hence they're not very good regression test cases. > I'd suggest using more restricting WHERE clauses, so that each query only > returns a handful of rows. > Thank you for comment, I rewrote wrong queries. But could you explain why LIMIT queries may return different results? Is it happens because of different query optimization? * I think it's leaking memory, in GIST scan context. I tested this with a > variant of the regression tests: > > insert into gist_tbl select box(point(0.05*i, 0.05*i), point(0.05*i, > 0.05*i)), > point(0.05*i, 0.05*i) FROM generate_series(0, > 10000000) as i; > CREATE INDEX gist_tbl_point_index ON gist_tbl USING gist (p); > > set enable_seqscan=off; > set enable_bitmapscan=off; > > explain analyze select p from gist_tbl where p <@ box(point(0,0), > point(9999999,9999999)) and length(p::text) < 10; > > while the final query runs, 'top' shows constantly increasing memory usage. I don't think it's memory leak. After some increasing, memory using remain the same. It works similar without using indexonlyscan. -- Best regards, Lubennikova Anastasia
