Re: Estimation problem with a LIKE clause containing a /

Поиск
Список
Период
Сортировка
От Guillaume Smet
Тема Re: Estimation problem with a LIKE clause containing a /
Дата
Msg-id 1d4e0c10711070538mf773791ke5950849299b142c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Estimation problem with a LIKE clause containing a /  ("Alexander Staubo" <alex@purefiction.net>)
Список 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 по дате отправления:

Предыдущее
От: "Alexander Staubo"
Дата:
Сообщение: Re: Estimation problem with a LIKE clause containing a /
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: index stat