Re: Puzzling planner choice (non-urgent)
От | Tom Lane |
---|---|
Тема | Re: Puzzling planner choice (non-urgent) |
Дата | |
Msg-id | 20718.1028557721@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Puzzling planner choice (non-urgent) (Richard Huxton <dev@archonet.com>) |
Ответы |
Re: Puzzling planner choice (non-urgent)
|
Список | pgsql-general |
Richard Huxton <dev@archonet.com> writes: > What I don't understand is the seq-scan on companies.co_id since it has a > unique index on it and *can't* match more than once for a given row while > looping through orders. Since the table is evidently only 2 pages long, the planner figures it's cheaper to read it all than to touch both the index and the table. The hole in this logic is that the cost estimate is made without regard for the fact that we're scanning the table repeatedly, and so at least the first few levels of index are likely to stay swapped in. I have some ideas about how to improve that, but dunno if it'll get done for 7.3. In the meantime you might try reducing random_page_cost to see if you like the results better. regards, tom lane
В списке pgsql-general по дате отправления: