Re: random_page_cost vs seq_page_cost

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: random_page_cost vs seq_page_cost
Дата
Msg-id CA+TgmoY4DBtqTX+ee8CMA55aoY169EX2wdXRSAv6twvdwg4TxQ@mail.gmail.com
обсуждение исходный текст
Ответ на random_page_cost vs seq_page_cost  (Benedikt Grundmann <bgrundmann@janestreet.com>)
Список pgsql-hackers
On Thu, Jan 5, 2012 at 5:04 AM, Benedikt Grundmann
<bgrundmann@janestreet.com> wrote:
> We are experiencing a big performance regression in some queries.
> In those cases the planner seems to choose a nested loop index
> scan instead of hashing the index once and then joining.

I think you probably need to post EXPLAIN ANALYZE output from the
actual queries to get useful advice, probably to pgsql-performance,
rather than here.

It's hard to believe that enable_nestloop=off is doing anything other
than masking whatever the real problem is, but it's hard to tell what
that problem is based on the information provided.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: FATAL: bogus data in lock file "postmaster.pid": ""
Следующее
От: Benedikt Grundmann
Дата:
Сообщение: Re: random_page_cost vs seq_page_cost