To: "Joshua D. Drake" <jd@commandprompt.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>,
	"Robert Treat" <xzilla@users.sourceforge.net>,
	<pgsql-hackers@postgresql.org>, "Peter Eisentraut" <peter_e@gmx.net>,
	"Greg Smith" <gsmith@gregsmith.com>,
	"Andreas Pflug" <pgadmin@pse-consulting.de>,
	"Decibel!" <decibel@decibel.org>,  "Josh Berkus" <josh@agliodbs.com>
Subject: Re: Overhauling GUCS
In-Reply-To: <1212800891.14299.35.camel@jd-laptop> (Joshua D. Drake's message
	of "Fri\, 06 Jun 2008 18\:08\:11 -0700")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <48409D1E.3070208@agliodbs.com> <29525.1212613052@sss.pgh.pa.us>
	<200806061435.01196.peter_e@gmx.net>
	<200806061624.29105.xzilla@users.sourceforge.net>
	<8358.1212797962@sss.pgh.pa.us> <1212800891.14299.35.camel@jd-laptop>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Mon, 09 Jun 2008 00:07:21 +0100
Message-ID: <87hcc3le52.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Joshua D. Drake" <jd@commandprompt.com> writes:

> On Fri, 2008-06-06 at 20:19 -0400, Tom Lane wrote:
>> Robert Treat <xzilla@users.sourceforge.net> writes:
>
>> Actually, the reason it's still 10 is that the effort expended to get it
>> changed has been *ZERO*.  I keep asking for someone to make some
>> measurements, do some benchmarking, anything to make a plausible case
>> for a specific higher value as being a reasonable place to set it.
>
>> The silence has been deafening.
>
> Not surprising really. It is a simple adjustment to make and it also is
> easy to spot when its a problem. However it is not trivial to test for
> (in terms of time and effort). I know 10 is wrong and so do you. If you
> don't I am curious why I see so many posts from you saying, "Your
> estimates are off, what is your default_statistics_target?" with yet
> even more responses saying, "Uhh 10." 

Ah, but we only ever hear about the cases where it's wrong of course. In other
words even if we raised it to some optimal value we would still have precisely
the same experience of seeing only posts on list about it being insufficient.

What's needed is some speed benchmarks for complex queries with varying size
statistics so we can see how badly large statistic tables hurt planning time. 

The flip side of seeing how much larger tables help planning accuracy is much
harder to measure. Offhand I don't see any systematic way to go about it.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's PostGIS support!