Re: Unexpected query plan results

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Unexpected query plan results
Дата
Msg-id 603c8f070905291515y1a451ba1j13462e78864ece6@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Unexpected query plan results  (Anne Rosset <arosset@collab.net>)
Ответы Re: Unexpected query plan results
Список pgsql-performance
On Fri, May 29, 2009 at 5:57 PM, Anne Rosset <arosset@collab.net> wrote:
> Robert Haas wrote:
>
>> On Thu, May 28, 2009 at 6:46 PM, Anne Rosset <arosset@collab.net> wrote:
>>
>>>
>>>                                                ->  Index Scan using
>>> item_pk on item  (cost=0.00..176865.31 rows=97498 width=88) (actual
>>> time=117.304..2405.060 rows=71 loops=1)
>>>                                                      Filter: ((NOT
>>> is_deleted) AND ((folder_id)::text = 'tracker3641'::text))
>>>
>>
>> The fact that the estimated row count differs from the actual row
>> count by a factor of more than 1000 is likely the root cause of your
>> problem here.  You probably want to figure out why that's happening.
>> How many rows are in that table and what value are you using for
>> default_statistics_target?
>>
>> ...Robert
>>
>
> The table has 468173 rows and the value for default_statistics_target is
> 750.
> Anne

OK, that sounds good.  If you haven't run ANALYZE or VACUUM ANALYZE
recently, you should do that first and see if it fixes anything.
Otherwise, maybe there's a hidden correlation between the deleted
column and the folder_id column.  We can assess that like this:

SELECT SUM(1) FROM item WHERE NOT deleted;
SELECT SUM(1) FROM item WHERE folder_id = 'tracker3641';
SELECT SUM(1) FROM item WHERE folder_id = 'tracker3641' AND NOT deleted;

Can you try that and send along the results?

Thanks,

...Robert

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

Предыдущее
От: Anne Rosset
Дата:
Сообщение: Re: Unexpected query plan results
Следующее
От: Brian Cox
Дата:
Сообщение: autovacuum hung?