Re: Shouldn't we have a way to avoid "risky" plans?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



25.03.11 16:12, Tom Lane ÐÐÐÐÑÐÐ(ÐÐ):
Vitalii Tymchyshyn<tivv00@xxxxxxxxx>  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



--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux