Re: Estimation problem with a LIKE clause containing a /

Alexander,

On 11/7/07, Alexander Staubo <alex(at)purefiction(dot)net> wrote:
> That's a difference of less than *three milliseconds* -- a difference
> probably way within the expected overhead of running "explain
> analyze". Furthermore, all three queries use the same basic plan: a
> sequential scan with a filter. At any rate you're microbenchmarking in
> a way that is not useful to real-world queries. In what way are these
> timings a problem?

If you read my previous email carefully, you'll see they aren't a
problem: the problem is the estimation, not the timing. This is a self
contained test case of a far more complex query which uses a bad plan
containing a nested loop due to the bad estimate.

> Now all "like 'prefix%'" queries should use the index.

Not when you retrieve 50% of this table of 22k rows but that's not my
problem anyway. A seqscan is perfectly fine in this case.

Thanks anyway.

--
Guillaume