After enabling the new likeplanning code, things only get worse... the
estimated cost for the same query is now:
Sort (cost=4.95..4.95 rows=1 width=136)
-> Index Scan using jennyann_target_key on jennyann (cost=0.00..4.94 rows=1 width=136)
So this doesn't really seem to help much. :)
Out of curiosity, why does it take so long to order data by a datetime
field?
On Sat, 3 Mar 2001, Tom Lane wrote:
> Ben <bench@silentmedia.com> writes:
> > Yes, it is horribly wrong.
> > select count(*) FROM jennyann where target like '/music/%'
> > gives me 93686 rows.
>
> Well, that misestimation is the source of the problem, then, not any
> misestimation of the cost of a sort.
>
> 7.0 didn't have very good estimation rules for LIKE clauses, at least
> not by default. Have you tried the new LIKE estimator (see
> contrib/likeplanning/README in the source tree)? I'm not sure it will
> do any better, given that your data appears to be mightily nonuniform
> ;-), but it's worth a try.
>
> regards, tom lane
>