From: Tom Lane <tgl@sss.pgh.pa.us>
To: Vitalii Tymchyshyn <tivv00@gmail.com>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: Claudio Freire <klaussfreire@gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Shouldn't we have a way to avoid "risky" plans?
Date: Fri, 25 Mar 2011 10:12:10 -0400
Message-ID: <2951.1301062330@sss.pgh.pa.us> (raw)
In-Reply-To: <4D8C63B2.1060800@gmail.com>
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>
Vitalii Tymchyshyn <tivv00@gmail.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, tivv00@gmail.com, mmoncure@gmail.com, klaussfreire@gmail.com, josh@agliodbs.com
Subject: Re: Shouldn't we have a way to avoid "risky" plans?
In-Reply-To: <2951.1301062330@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox