Re: Why does the number of rows are different in actual and estimated.
От | Claudio Freire |
---|---|
Тема | Re: Why does the number of rows are different in actual and estimated. |
Дата | |
Msg-id | CAGTBQpaGP8j9FKLmR=8rFaxTtnfr6iozEbJF8sDt8_gz1ZQtkA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Why does the number of rows are different in actual and estimated. (Evgeny Shishkin <itparanoia@gmail.com>) |
Ответы |
Re: Why does the number of rows are different in actual and estimated.
|
Список | pgsql-performance |
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 by2257 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 по дате отправления: