Re: Revisiting default_statistics_target

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Mark Wong <markwkm(at)gmail(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Revisiting default_statistics_target
Date: 2009-06-07 16:13:22
Message-ID: 14622.1244391202@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Sat, 2009-06-06 at 12:06 -0700, Josh Berkus wrote:
>> Well, Jignesh and I identified two things which we think are "special"
>> about DBT2: (1) it uses C stored procedures, and (2) we don't think it
>> uses prepared plans.

> If there is a performance regression it is almost certain to effect
> planning; obviously if there is no planning there is no effect.

Yeah; on a benchmark that relies mainly on prepared plans, it'd be
unlikely you'd notice any effect at all, even from a very significant
increase in planning time.

My guess about the "C stored procedure" bit, if it really has any
relevance, is that it reduces the other overhead of the test case enough
that planning time becomes more significant than it would be in other
benchmark scenarios.

In any case, what we seem to have here is evidence that there are some
cases where the new default value of default_statistics_target is too
high and you can get a benefit by lowering it. I'm not sure we should
panic about that. Default values ought to be compromises. If people
only ever change the default in one direction then it's probably not a
very good compromise. We know that there are applications for which 100
is still too low, so maybe now we have got the pain spread out roughly
evenly...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-06-07 16:34:22 Re: Revisiting default_statistics_target
Previous Message Tom Lane 2009-06-07 16:03:41 Re: pg_migrator issue with contrib