Re: Weird issue with planner choosing seq scan
От | Tom Lane |
---|---|
Тема | Re: Weird issue with planner choosing seq scan |
Дата | |
Msg-id | 5289.1203875431@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Weird issue with planner choosing seq scan (Sean Leach <sleach@wiggum.com>) |
Ответы |
Re: Weird issue with planner choosing seq scan
Re: Weird issue with planner choosing seq scan |
Список | pgsql-performance |
Sean Leach <sleach@wiggum.com> writes: > I have a table, that in production, currently has a little over 3 > million records in production. In development, the same table has > about 10 million records (we have cleaned production a few weeks > ago). You mean the other way around, to judge by the rowcounts from EXPLAIN. > -> Index Scan using u_counts_i2 on u_counts c > (cost=0.00..53.53 rows=1082 width=4) (actual time=0.277..1224.582 > rows=392173 loops=1) I kinda think the devel system wouldn't be using an indexscan either if it had up-to-date ANALYZE statistics. But even with the 1082 row estimate that seems a remarkably low cost estimate. Have you been playing games with random_page_cost? Maybe you forgot to duplicate the devel system's cost parameters onto the production system? regards, tom lane
В списке pgsql-performance по дате отправления: