Re: Range Types - efficiency
От | Chris Browne |
---|---|
Тема | Re: Range Types - efficiency |
Дата | |
Msg-id | 87y65oyfh9.fsf@cbbrowne.afilias-int.info обсуждение исходный текст |
Ответ на | Range Types - representation and alignment (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Range Types - efficiency
|
Список | pgsql-hackers |
pgsql@j-davis.com (Jeff Davis) writes: > On Wed, 2011-02-09 at 16:20 -0500, Chris Browne wrote: >> rangetest@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: > > Yes. The index is a btree index on a normal column, so range types can't > exactly help with that directly -- except maybe as a rewrite like you > say. > > One thing you might try is a functional index on (range(whensit)) and > then do: where '...' @> range(whensit). > > Does that work for you? That doesn't appear to actually help: rangetest@localhost-> create index i2 on some_data (range(whensit)); CREATE INDEX rangetest@localhost-> explain analyze select * from some_data where '[2010-01-01,2010-02-01)'::daterange @> range(whensit); QUERY PLAN -------------------------------------------------------------------------------------------------------------Seq Scan onsome_data (cost=0.00..727.60 rows=12480 width=8) (actual time=1.030..110.542 rows=390 loops=1) Filter: ('[ 2010-01-01,2010-02-01 )'::daterange @> range(whensit))Total runtime: 110.585 ms (3 rows) In any case, I suggest that as a "couple steps down the road" thing, it would be desirable to have that query rewrite. Seems like a reasonable ToDo item to consider for the future, if not in the first deployment. Maybe that's something to add in 9.2 CommitFest #3! :-) -- "There isn't any reason why Linux can't be implemented as an enterprise computing solution. Find out what you've been missing while you've been rebooting Windows NT." - Infoworld
В списке pgsql-hackers по дате отправления: