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

From: Nathan Boley <npboley(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Claudio Freire <klaussfreire(at)gmail(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 22:43:04
Message-ID: AANLkTimsr54ST-M7Tt=VA1nOJWN2DtUS_LhjPT+CwY3W@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> mergejoinscansel doesn't currently try to fix up the histogram bounds by
> consulting indexes.  At the time I was afraid of the costs of doing
> that, and I still am; but it would be a way to address this issue.
>

Another cheaper but less accurate way to deal with this is to note
that we are trying to estimate the max of the population by using the
max of the sample, which obviously has a negative bias. If we could
correct the bias ( though the bootstrap, or an analytical correction
under some parametric assumptions ( ie, the distribution is uniform in
the last bucket ) ) , then we should get better estimates at the cost
of some analyze time. But this wouldn't even deal with Josh's
particular problem, since it's due to out of date stats rather than
sampling error...

-Nathan

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Joshua Berkus 2011-03-26 01:03:17 Re: Shouldn't we have a way to avoid "risky" plans?
Previous Message Scott Carey 2011-03-25 17:55:08 Re: Shouldn't we have a way to avoid "risky" plans?