DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	b=t78qWz7eU1fEDGQpO5fo5suUti9sHxZF14QyousodtGA/0Y1t4tRH7gFFmbQAz2mi/
	9T46hWn/HQD86NyZ8mtDqbt5YVzM7fwH5tq3DrPv0cb30tNfLudK7KfqR+Mmuv0ouup0
	50LlA6/Jtj5+jOuQUj2n41tUG5wn4jsWZ1Uz4=
Message-ID: <4D8CA989.2080904@gmail.com>
Date: Fri, 25 Mar 2011 16:41:13 +0200
From: Vitalii Tymchyshyn <tivv00@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Merlin Moncure <mmoncure@gmail.com>,
	Claudio Freire <klaussfreire@gmail.com>, Josh Berkus <josh@agliodbs.com>,
	postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Shouldn't we have a way to avoid "risky" plans?
References: <4D8A29F2.9080105@agliodbs.com>
	<AANLkTi=GAz7gFBCoXQeRDN3PUA0fXxRyP_=DxS4Y1tJU@mail.gmail.com>
	<4D8A581D.5080704@agliodbs.com>
	<AANLkTi=RXUSrCxqz3=BkAiixuenu2gf-K+W15Wz4McXH@mail.gmail.com>
	<4286.1300914004@sss.pgh.pa.us>
	<AANLkTim-SKShZUxD55ZuHHHLgYuY_MzSSPm6GNYR_fYW@mail.gmail.com>
	<AANLkTin3xcE9deHQ14kow2b0H_MPZMUmGFm-ZAGfU==z@mail.gmail.com>
	<4D8C63B2.1060800@gmail.com> <2951.1301062330@sss.pgh.pa.us>
In-Reply-To: <2951.1301062330@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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