From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Timur Irmatov <thor(at)sarkor(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: index usage |
Date: | 2003-01-17 14:57:04 |
Message-ID: | 11751.1042815424@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Timur Irmatov <thor(at)sarkor(dot)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=0 loops=1)
The planner has absolutely no clue about the behavior of your function,
and so its estimate of the number of rows matched is way off, leading to
a poor estimate of the cost of an indexscan. There is not much to be
done about this in the current system (though I've speculated about the
possibility of computing statistics for functional indexes).
Just out of curiosity, why don't you lose all this year/month/day stuff
and use a timestamp column? Less space, more functionality.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Timur Irmatov | 2003-01-17 15:08:14 | Re: index usage |
Previous Message | Roman Fail | 2003-01-17 14:48:28 | Implicit casting and JOIN syntax constraints |