On 09/19/2014 11:38 PM, Greg Stark wrote: > > On 19 Sep 2014 19:40, "Josh Berkus" <josh@xxxxxxxxxxxx > <mailto:josh@xxxxxxxxxxxx>> wrote: >> >> On 09/19/2014 10:15 AM, Merlin Moncure wrote: >> > On Wed, Sep 17, 2014 at 7:11 PM, Josh Berkus <josh@xxxxxxxxxxxx > <mailto:josh@xxxxxxxxxxxx>> wrote: >> >> This is the core issue with abort-early plans; they depend on our >> >> statistics being extremely accurate, which we know they are not. And if >> >> they're wrong, the execution time climbs by 1000X or more. Abort-early >> >> plans are inherently riskier than other types of query plans. > > All plans are risky if the stats are wrong. It's one of the perennial > digressions that many postgres newcomers make to track worst case costs > and provide a knob for planner aggressiveness but it always breaks down > when you try to quantify the level of risk because you discover that > even such simple things as indeed scans versus sequential scans can be > equally risky either way. I've had a *wee* bit more experience with query plans than most Postgres newcomers, Greg. While all query plan changes can result in regressions if they're bad, there are certain kinds of plans which depend more on accurate stats than others. Abort-early plans are the most extreme of these. Most likely we should adjust the cost model for abort-early plans to take in our level of uncertainty, especially since we *know* that our n-distinct estimation is crap. For example, we could increase the estimated cost for an abort-early index scan by 10X, to reflect our weak confidence in its correctness. We could also probably do the same for plans which depend on column correlation estimates being accurate. > >> >> What I'm not clear on is why upgrading from 9.1 to 9.3 would bring > about >> >> this change. The stats are no more than 10% different across the >> >> version change. > > There's no difference. Postgres has been estimating LIMIT costs this way > since before I came to postgres in 7.3. Then why is the plan different in 9.1 and 9.3 with identical stats (I tested)? > > It would be neat to have an opclass which worked like that. Which would > amount to having prefix compression perhaps. > > What plan does 9.1 come up with? That was the "good" plan from my original post. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
