Re: Query plan prefers hash join when nested loop is much faster

Поиск
Список
Период
Сортировка
От iulian dragos
Тема Re: Query plan prefers hash join when nested loop is much faster
Дата
Msg-id CAMNsu3mGt350XkwXUNhJO0LKuQ96X22NFqjapg=SRY+vo3H3gg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Query plan prefers hash join when nested loop is much faster  (Michael Lewis <mlewis@entrata.com>)
Ответы Re: Query plan prefers hash join when nested loop is much faster  (iulian dragos <iulian.dragos@databricks.com>)
Список pgsql-general
Hi Michael,

Thanks for the answer. It's an RDS instance using SSD storage and the default `random_page_cost` set to 4.0. I don't expect a lot of repetitive queries here, so I think caching may not be extremely useful. I wonder if the selectivity of the query is wrongly estimated (out of 500 million rows, only a few thousands are returned).

I tried lowering the `random_page_cost` to 1.2 and it didn't make a difference in the query plan.

iulian


On Fri, Aug 21, 2020 at 6:30 PM Michael Lewis <mlewis@entrata.com> wrote:
Your system is preferring sequential scan to using test_result_module_result_id_idx in this case. What type of storage do you use, what type of cache hits do you expect, and what do you have random_page_cost set to? That comes to mind as a significant factor in choosing index scans based on costs.

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

Предыдущее
От: harish supare
Дата:
Сообщение: Re: Substitute Variable in select query
Следующее
От: Diego
Дата:
Сообщение: Re: Getting away from Oracle APEX, recommendations for PostgreSQL?