Re: Why is explain horribly optimistic for sorts?

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
>