Re: Why does the number of rows are different in actual and estimated.

Поиск
Список
Период
Сортировка
От AI Rumman
Тема Re: Why does the number of rows are different in actual and estimated.
Дата
Msg-id CAGoODpcRAJP0xAXrjeB2oUQ1hj+fVtbxW76ggqWXcZJCmUPZoA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why does the number of rows are different in actual and estimated.  (Claudio Freire <klaussfreire@gmail.com>)
Ответы Re: Why does the number of rows are different in actual and estimated.  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-performance
Does FK Constraint help to improve performance? Or it is only for maintaining data integrity?

On Thu, Dec 13, 2012 at 7:38 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
On Thu, Dec 13, 2012 at 8:50 PM, Evgeny Shishkin <itparanoia@gmail.com> wrote:
>>> OP joins 8 tables, and i suppose join collapse limit is set to default 8. I thought postgresql's optimiser is not mysql's.
>>
>> It's not obvious to me that there's anything very wrong with the plan.
>> An 8-way join that produces 150K rows is unlikely to run in milliseconds
>> no matter what the plan.  The planner would possibly have done the last
>> join step differently if it had had a better rowcount estimate, but even
>> if that were free the query would still have been 7 seconds (vs 8.5).
>>
>
> May be in this case it is. I once wrote to this list regarding similar problem - joining 4 tables, result set are off by 2257 times - 750ms vs less then 1ms. Unfortunately the question was not accepted to the list.
>
> I spoke to Bruce Momjian about that problem on one local conference, he said shit happens :)

I think it's more likely a missing FK constraint.

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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: backend suddenly becomes slow, then remains slow
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: Why does the number of rows are different in actual and estimated.