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
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 |