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
