Range Types - efficiency

One of the things I'd particularly like to use range types for is to
make it easier to construct range-related queries. Classic example is
that of reports that work on date ranges.

I create a table that will have transaction data:

CREATE TABLE some_data (
id serial,
whensit date
-- And it'll have other attributes, but those don't matter here...
);
CREATE INDEX some_when ON some_data USING btree (whensit);

I then populate it with a bunch of date-based data...

rangetest(at)localhost-> select count(*), min(whensit), max(whensit) from some_data;
count | min | max
-------+------------+------------
37440 | 2007-01-01 | 2014-12-27
(1 row)

Here's the traditional way of doing a range-based query on this data:

rangetest(at)localhost-> explain analyze select * from some_data where whensit >= '2010-01-01' and whensit < '2010-02-01';
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on some_data (cost=12.30..184.23 rows=395 width=8) (actual time=0.064..0.150 rows=390 loops=1)
Recheck Cond: ((whensit >= '2010-01-01'::date) AND (whensit < '2010-02-01'::date))
-> Bitmap Index Scan on some_when (cost=0.00..12.21 rows=395 width=0) (actual time=0.054..0.054 rows=390 loops=1)
Index Cond: ((whensit >= '2010-01-01'::date) AND (whensit < '2010-02-01'::date))
Total runtime: 0.197 ms
(5 rows)

The RangeType-based equivalent is the following:

rangetest(at)localhost-> explain analyze select * from some_data where '[2010-01-01,2010-02-01)'::daterange @> whensit;
QUERY PLAN
---------------------------------------------------------------------------------------------------------
Seq Scan on some_data (cost=0.00..634.00 rows=1 width=8) (actual time=1.045..111.739 rows=390 loops=1)
Filter: ('[ 2010-01-01, 2010-02-01 )'::daterange @> whensit)
Total runtime: 111.780 ms
(3 rows)

This, alas, reverts to a seq scan on the table, rather than restricting
itself to the tuples of interest.

I realize that, after a fashion, I'm using this backwards. But when I'm
doing temporal stuff, that tends to be the pattern:

- There is a set of temporal configuration, indicating criteria that
are true for particular date ranges

- There is then event data, which has but a single date, but which
needs to be matched against the temporal configuration.

It sure would be nice to expand that filter into subqueries involving
the two criteria, in much the same fashion that is true today for
BETWEEN. I imagine that would allow many queries with this kind of
pattern to make use of indexes, making them visibly thousands of times
faster.
--
"I have traveled the length and breadth of this country and talked
with the best people, and can assure you that data processing is a fad
that won't last out the year". -- Business books editor, Prentice
Hall 1957