[HACKERS] Range Types regression failure
Hi, I can't explain why I'm seeing a range type installcheck failure as I don't see the same problem on the buildfarm, but out of all the tests run, the range types test is the only one to fail. I've attached the diff and the rangetypes.out file. It appears that while the rows output are the same, they aren't in the same order. What I can't explain is why the ordering on my system is different to all the buildfarm animals. This is on Ubuntu 11.10 64-bit (Linux kernel 3.0.0) and the following build options: --enable-depend --enable-cassert --enable-debug --with-ossp-uuid --with-libxml --with-libxslt -- Thom regression.diffs Description: Binary data rangetypes.out Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Range Types regression failure
Thom Brown t...@linux.com writes: I can't explain why I'm seeing a range type installcheck failure as I don't see the same problem on the buildfarm, but out of all the tests run, the range types test is the only one to fail. I can duplicate that output ordering if I force it to use indexscans, but it's quite unclear why it would do so by default for a six-row table. Are you using weird planner cost parameters? (I'd have expected such to result in a lot more diffs than this, though.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Range Types regression failure
On 6 April 2012 22:35, Tom Lane t...@sss.pgh.pa.us wrote: Thom Brown t...@linux.com writes: I can't explain why I'm seeing a range type installcheck failure as I don't see the same problem on the buildfarm, but out of all the tests run, the range types test is the only one to fail. I can duplicate that output ordering if I force it to use indexscans, but it's quite unclear why it would do so by default for a six-row table. Are you using weird planner cost parameters? (I'd have expected such to result in a lot more diffs than this, though.) Ah, you've nailed it. It's performing an index-only scan: thom@regression=# explain select * from numrange_test where nr numrange(-1000.0, -1000.0,'[]'); QUERY PLAN -- Index Only Scan using numrange_test_btree on numrange_test (cost=0.00..20.00 rows=437 width=32) Index Cond: (nr '[-1000.0,-1000.0]'::numrange) (2 rows) And you are right about my cost settings. I have random_page_cost set to 1.1 as I'm using an SSD. Setting it back to 4.0 and re-running the tests removes the issue. My fault for swapping in my edited conf file prior to tests. Thanks. -- Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
