Re: index scan of whole table, can't see why

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: index scan of whole table, can't see why
Дата
Msg-id 20050120061205.T35934@megazone.bigpanda.com
обсуждение исходный текст
Ответ на index scan of whole table, can't see why  ("Dan Langille" <dan@langille.org>)
Ответы Re: index scan of whole table, can't see why
Список pgsql-performance
On Wed, 19 Jan 2005, Dan Langille wrote:

> Hi folks,
>
> Running on 7.4.2, recently vacuum analysed the three tables in
> question.
>
> The query plan in question changes dramatically when a WHERE clause
> changes from ports.broken to ports.deprecated.  I don't see why.
> Well, I do see why: a sequential scan of a 130,000 rows.  The query
> goes from 13ms to 1100ms because the of this.  The full plans are at
> http://rafb.net/paste/results/v8ccvQ54.html
>
> I have tried some tuning by:
>
>   set effective_cache_size to 4000, was 1000
>   set random_page_cost to 1, was 4
>
> The resulting plan changes, but no speed improvment, are at
> http://rafb.net/paste/results/rV8khJ18.html
>
> Any suggestions please?

As a question, what does it do if enable_hashjoin is false? I'm wondering
if it'll pick a nested loop for that step for the element/ports join and
what it estimates the cost to be.


В списке pgsql-performance по дате отправления:

Предыдущее
От: Hervé Piedvache
Дата:
Сообщение: PostgreSQL clustering VS MySQL clustering
Следующее
От: Jean-Max Reymond
Дата:
Сообщение: Re: PostgreSQL clustering VS MySQL clustering