Re: Range Types regression failure

From: Thom Brown <thom(at)linux(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Range Types regression failure
Date: 2012-04-06 21:46:25
Message-ID: CAA-aLv4Vb+p1X4_CNsoZnngR0fx5VqR2dUCrzrw169==hKBRtQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6 April 2012 22:35, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thom Brown <thom(at)linux(dot)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(at)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Nolan 2012-04-06 21:54:54 Re: 9.1.3 Standby catchup mode
Previous Message Tom Lane 2012-04-06 21:35:23 Re: Range Types regression failure