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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>
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:12:10
Message-ID: 2951.1301062330@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Vitalii Tymchyshyn <tivv00(at)gmail(dot)com> writes:
> 24.03.11 20:41, Merlin Moncure ():
>> ISTM if you add statistics miss and 'risk margin' to the things the
>> planner would have to consider while generating a plan, you are
>> greatly increasing the number of plan paths that would have to be
>> considered for any non trivial query.

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2011-03-25 14:24:44 Re: Shouldn't we have a way to avoid "risky" plans?
Previous Message Shaun Thomas 2011-03-25 13:24:55 Re: Why Index is not used