Thread

1. Range Types regression failure

   Thom Brown <thom@linux.com> — 2012-04-06T21:09:49Z

   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
   

2. Re: Range Types regression failure

   Tom Lane <tgl@sss.pgh.pa.us> — 2012-04-06T21:35:23Z

   Thom Brown <thom@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
   
   

3. Re: Range Types regression failure

   Thom Brown <thom@linux.com> — 2012-04-06T21:46:25Z

   On 6 April 2012 22:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
   > Thom Brown <thom@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