Re: Revisiting default_statistics_target

On 22 May 2009, at 16:17, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:

> On Fri, 22 May 2009, Greg Sabino Mullane wrote:
>
>>> The bump from 10 to 100 was supported by microbenchmarks that
>>> suggested it
>>> would be tolerable.
>>
>> No, the 10 to 100 was supported by years of people working in the
>> field who
>> routinely did that adjustment (and >100) and saw great gains.
>
> No one is suggesting the increase isn't important to people running
> many common workloads. The question the smaller benchmarks tried to
> answer is whether it was likely to detune anything else as a penalty
> for improving that situation.

As Tom implied there are two possible problems and the response would
be different depending on what's going on.

If the plan changed due to the added stats and the new plan is worse
then it's a problem but the lowering the stats target would just be
papering over the problem. Ideally having better stats should never
cause a worse plan.

If on the other hand it turns out that planning the queries is taking
15% longer the, well then we should rerun the microbenchmark using
these queries might give us a better default.

Or maybe we would just find the bottlenecks and fix them ...

> The comments you made here can get turned right around at you: if
> increasing the value in the field is sufficient to help out those
> that need it, why should the project at large accept any significant
> penalty that could apply to everyone just to help that subset?
>
> Would you be happy with 8.4 going out the door if there really turns
> out to be a 15% penalty for other use cases by this change? That's
> a PR nightmare waiting to happen, and the main reason I wanted to
> bring this up here with some additional details as soon as Jignesh's
> slides went public--so everyone here is aware of what's going on
> before this bit of news gets picked up anywhere else.
>
> Hopefully whatever is happening to dbt2 will turn out to be a quirk
> not worth worrying about. What if it turns out to be repeatable and
> expected to impact people in the field though? I hope you'd
> recognize that your use case is no more privileged to trump other
> people's than the changes that would be good for DW users, but not
> anyone else, that you were just making critical comments about.
>
> Anyway, thanks to Stephen for concisely clarifying the position I
> was trying to present here, which is quite different from the one
> you were arguing against.
>
> --
> * Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com
> Baltimore, MD
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers