Re: Shouldn't we have a way to avoid "risky" plans?
От | Vitalii Tymchyshyn |
---|---|
Тема | Re: Shouldn't we have a way to avoid "risky" plans? |
Дата | |
Msg-id | 4D8CA989.2080904@gmail.com обсуждение исходный текст |
Ответ на | Re: Shouldn't we have a way to avoid "risky" plans? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
25.03.11 16:12, Tom Lane написав(ла): > Vitalii Tymchyshyn<tivv00@gmail.com> writes: > >> Why so? I simply change cost estimation functions. This won't change >> number of pathes. > If you have multiple figures of merit, that means you have to keep more > paths, with consequent slowdown when it comes to choosing which path to > use at higher join levels. > > As an example, we used to keep only the paths with best total cost. > When we started to optimize LIMIT, we had to keep around paths with best > startup cost too, in case that made for the best combined result at a > higher join level. If you're going to consider "risk" while choosing > paths, that means you'll start keeping paths you would have discarded > before, while not necessarily getting rid of any other paths. The only > way to avoid that would be to have a completely brain-dead notion of > risk that wasn't affected by how the path is used at a higher join > level, and I'm pretty sure that that wouldn't solve anybody's problem. > > Any significant expansion of the planner's fundamental cost model *will* > make it slower. By a lot. Rather than going into this with fantasies > of "it won't cost anything", you should be worrying about how to keep > the speed penalty to factor-of-two rather than factor-of-ten. But I am not talking about model change, it's more like formula change. Introducing limit added one variable where outer plan could influence inner plan selection. But I am talking simply about cost calculation for given node. Now cost is based on statistical expected value, the proposal is (something like) to take maximum cost on n% probability range near expected value. This, of course, will make calculations slower, but won't add any degree of freedom to calculations. Best regards, Vitalii Tymchyshyn
В списке pgsql-performance по дате отправления: