pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Gregory Stark <stark@enterprisedb.com>
To: Joshua D. Drake <jd@commandprompt.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Treat <xzilla@users.sourceforge.net>
Cc: pgsql-hackers@postgresql.org
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: Andreas Pflug <pgadmin@pse-consulting.de>
Cc: Decibel! <decibel@decibel.org>
Cc: Josh Berkus <josh@agliodbs.com>
Subject: Re: Overhauling GUCS
Date: Mon, 09 Jun 2008 00:07:21 +0100
Message-ID: <87hcc3le52.fsf@oxford.xeocode.com> (raw)
In-Reply-To: <1212800891.14299.35.camel@jd-laptop>
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>

"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!



view thread (226+ messages)  latest in thread

Message-ID: <87hcc3le52.fsf@oxford.xeocode.com>
Permalink:  ../87hcc3le52.fsf@oxford.xeocode.com/
Also on:    postgresql.org/message-id/87hcc3le52.fsf@oxford.xeocode.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: stark@enterprisedb.com, jd@commandprompt.com, tgl@sss.pgh.pa.us, xzilla@users.sourceforge.net, peter_e@gmx.net, gsmith@gregsmith.com, pgadmin@pse-consulting.de, decibel@decibel.org, josh@agliodbs.com
  Subject: Re: Overhauling GUCS
  In-Reply-To: <87hcc3le52.fsf@oxford.xeocode.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox