Re: Estimation problem with a LIKE clause containing a /

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alexander,

On 11/7/07, Alexander Staubo <alex@xxxxxxxxxxxxxxx> 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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux