Re: Estimation problem with a LIKE clause containing a / - Mailing list pgsql-performance

From Guillaume Smet
Subject Re: Estimation problem with a LIKE clause containing a /
Date
Msg-id 1d4e0c10711070538mf773791ke5950849299b142c@mail.gmail.com
Whole thread Raw
In response to Re: Estimation problem with a LIKE clause containing a /  ("Alexander Staubo" <alex@purefiction.net>)
List pgsql-performance
Alexander,

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

pgsql-performance by date:

Previous
From: "Alexander Staubo"
Date:
Subject: Re: Estimation problem with a LIKE clause containing a /
Next
From: "Kevin Grittner"
Date:
Subject: Re: index stat