Re: Sort and index

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Sort and index
Дата
Msg-id 4269.1114222086@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Sort and index  ("Jim C. Nasby" <decibel@decibel.org>)
Ответы Re: Sort and index  ("Jim C. Nasby" <decibel@decibel.org>)
Список pgsql-performance
"Jim C. Nasby" <decibel@decibel.org> writes:
> I've run some performance tests. The actual test case is at
> http://stats.distributed.net/~decibel/timing.sql, and the results are at
> http://stats.distributed.net/~decibel/timing.log. In a nutshell, doing
> an index scan appears to be about 2x faster than a sequential scan and a
> sort.

... for one test case, on one platform, with a pretty strong bias to the
fully-cached state since you ran the test multiple times consecutively.

Past experience has generally been that an explicit sort is quicker,
so you'll have to pardon me for suspecting that this case may be
atypical.  Is the table nearly in order by pkey, by any chance?

> In any case, it's clear that the planner is making the wrong choice
> here. BTW, changing random_page_cost to 3 or 4 doesn't change the plan.

Feel free to propose better cost equations.

            regards, tom lane

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

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Joel's Performance Issues WAS : Opteron vs Xeon
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Joel's Performance Issues WAS : Opteron vs Xeon