Re: how to improve perf of 131MM row table?

Поиск
Список
Период
Сортировка
От Shaun Thomas
Тема Re: how to improve perf of 131MM row table?
Дата
Msg-id 53AC491A.8090207@optionshouse.com
обсуждение исходный текст
Ответ на Re: how to improve perf of 131MM row table?  (Claudio Freire <klaussfreire@gmail.com>)
Ответы Re: how to improve perf of 131MM row table?  (AJ Weber <aweber@comcast.net>)
Список pgsql-performance
On 06/26/2014 11:19 AM, Claudio Freire wrote:

> Try changing node_id in (...) into node.id in (...)

Wow. How did we not see that earlier? That's probably the issue. If you
look at the estimates of his query:

Bitmap Heap Scan on alf_node_properties prop  (cost=1253.19..189491.87
rows=52790 width=179) (actual time=0.571..1.349 rows=1071 loops=1)

The planner is off by an order of magnitude, and since the matches are
against node_id instead of node.id, it thinks it would have to index
seek on the alf_node table for over 50k rows. I could easily see it
opting for a sequence scan in that case, depending on how high
random_page_cost is.

--
Shaun Thomas
OptionsHouse, LLC | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas@optionshouse.com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email


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

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: how to improve perf of 131MM row table?
Следующее
От: Sébastien Lorion
Дата:
Сообщение: Re: how to improve perf of 131MM row table?