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  (Sean Leach <sleach@wiggum.com>)
Re: Weird issue with planner choosing seq scan  (Matthew <matthew@flymine.org>)
Список 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 по дате отправления:

Предыдущее
От: Sean Leach
Дата:
Сообщение: Weird issue with planner choosing seq scan
Следующее
От: Sean Leach
Дата:
Сообщение: Re: Weird issue with planner choosing seq scan