Skip site navigation (1) Skip section navigation (2)

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

From: Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Shouldn't we have a way to avoid "risky" plans?
Date: 2011-03-25 14:41:13
Message-ID: 4D8CA989.2080904@gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
25.03.11 16:12, Tom Lane написав(ла):
> Vitalii Tymchyshyn<tivv00(at)gmail(dot)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



In response to

pgsql-performance by date

Next:From: Maciek SakrejdaDate: 2011-03-25 16:49:31
Subject: Re: Why Index is not used
Previous:From: Strange, John WDate: 2011-03-25 14:25:45
Subject: Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group