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=WGqjXUSyWDE40Dcjsu4eCF1wYPcZ/PsCe3dGg5Pi0N/vXuKO9cJBcXFacQOqkx8FV4
	CCNtfMm6YdimiwMIyzFhF5NxDzb7mUqFpSflICcljQS+qfFjLamDgDfeRuAu2uBKlgO4
	joojJtwpRf0hn0AV17aw9bQGXzGL569QYKOKo=
Message-ID: <4D8C63B2.1060800@gmail.com>
Date: Fri, 25 Mar 2011 11:43:14 +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: Merlin Moncure <mmoncure@gmail.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, 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>
In-Reply-To: <AANLkTin3xcE9deHQ14kow2b0H_MPZMUmGFm-ZAGfU==z@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-U; format=flowed
Content-Transfer-Encoding: 8bit

24.03.11 20:41, Merlin Moncure написав(ла):
> 2011/3/24 Віталій Тимчишин<tivv00@gmail.com>:
>>
>> This can se GUC-controllable. Like plan_safety=0..1 with low default value.
>> This can influence costs of plans where cost changes dramatically with small
>> table changes and/or statistics is uncertain. Also this can be used as
>> direct "hint" for such dangerous queries by changing GUC for session/single
>> query.
> 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.

Best regards, Vitalii Tymchyshyn.