Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 4165D65032F for ; Thu, 11 Dec 2008 18:29:51 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 93126-07 for ; Thu, 11 Dec 2008 18:29:48 -0400 (AST) X-Greylist: delayed 07:17:38.192309 by SQLgrey-1.7.6 Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mail.postgresql.org (Postfix) with ESMTP id 238B86501CA for ; Thu, 11 Dec 2008 18:29:48 -0400 (AST) Received: by an-out-0708.google.com with SMTP id d14so525399and.28 for ; Thu, 11 Dec 2008 14:29:46 -0800 (PST) Received: by 10.64.213.8 with SMTP id l8mr2505287qbg.3.1229034585855; Thu, 11 Dec 2008 14:29:45 -0800 (PST) Received: from oxford.xeocode.com.enterprisedb.com (206-248-162-62.dsl.teksavvy.com [206.248.162.62]) by mx.google.com with ESMTPS id k8sm4783533qba.25.2008.12.11.14.29.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 14:29:44 -0800 (PST) To: Simon Riggs Cc: Tom Lane , Robert Haas , Kevin Grittner , "jd\@commandprompt.com" , Josh Berkus , Greg Smith , pgsql-hackers@postgresql.org Subject: Re: benchmarking the query planner In-Reply-To: <1229033073.13078.179.camel@hp_dx2400_1> (Simon Riggs's message of "Thu\, 11 Dec 2008 22\:04\:33 +0000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:HACKERS" 50905) References: <603c8f070812061019r5aca3aajeaa5493b11c5feff@mail.gmail.com> <9897C4AF-6D47-4F44-AD3D-F5A82AC392DB@enterprisedb.com> <87ljuq4rmk.fsf@oxford.xeocode.com> <603c8f070812092025k6325e0fcud001b205a507a634@mail.gmail.com> <4313.1228931932@sss.pgh.pa.us> <603c8f070812101828p1bd7df49yb8c916adedb49fe1@mail.gmail.com> <9565.1229018968@sss.pgh.pa.us> <1229033073.13078.179.camel@hp_dx2400_1> From: Gregory Stark Organization: EnterpriseDB Date: Thu, 11 Dec 2008 22:29:38 +0000 Message-ID: <87ej0etkfh.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200812/821 X-Sequence-Number: 129450 Simon Riggs writes: > On Thu, 2008-12-11 at 13:09 -0500, Tom Lane wrote: > >> On the whole I think we have some evidence here to say that upping the >> default value of default_stats_target to 100 wouldn't be out of line, >> but 1000 definitely is. Comments? > > Sounds good to me. > > I would like it even more if there was a data type specific default. > Currently we have a special case for boolean, but that's it. TPC allows > for different defaults for different types (but that's not my only > reason). That would allow us to set it lower for long text strings and > floats and potentially higher for things like smallint, which is less > likely as a join target. In conjunction with a toast rethink it would be interesting to engineer things so that we keep one page's worth of data after toasting for each of the arrays. That would at least remove a lot of the dangers of larger arrays. > Would be great if we could set the default_stats_target for all columns > in a table with a single ALTER TABLE statement, rather than setting it > for every column individually. Hm, just because one column has a skewed data distribution doesn't tell you much about what the other columns' data distributions are. On the other hand I could see an argument that a given table might be consistently used in only large batch queries or quick OLTP queries. > And I would like it even more if the sample size increased according to > table size, since that makes ndistinct values fairly random for large > tables. Unfortunately _any_ ndistinct estimate based on a sample of the table is going to be pretty random. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!