TL> Timur Irmatov <thor@sarkor.com> writes:
>> Limit (cost=0.00..0.19 rows=1 width=6) (actual time=0.43..0.43 rows=0 loops=1)
>> -> Index Scan using timeindex on mediumstats (cost=0.00..2898.96 rows=15185 width=6) (actual time=0.42..0.42
rows=0loops=1)
TL> The planner has absolutely no clue about the behavior of your function,
TL> and so its estimate of the number of rows matched is way off, leading to
TL> a poor estimate of the cost of an indexscan. There is not much to be
TL> done about this in the current system (though I've speculated about the
TL> possibility of computing statistics for functional indexes).
you're absolutely right.
thanks.
TL> Just out of curiosity, why don't you lose all this year/month/day stuff
TL> and use a timestamp column? Less space, more functionality.
:-)
Well, I've a seen a lot of people on pgsql-general mailing list with
problems with dates, timestamps, and I was just scared of using
PostreSQL date and time types and functions..
May be, I should just try it myself before doing it other way...
