Thread: Range Types regression failure

Range Types regression failure

From
Thom Brown
Date:
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

Attachment

Re: Range Types regression failure

From
Tom Lane
Date:
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


Re: Range Types regression failure

From
Thom Brown
Date:
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_btreeon 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