Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 32AB79FB552 for ; Wed, 20 Jun 2007 03:45:34 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 74240-01 for ; Wed, 20 Jun 2007 03:45:30 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from westnet.com (westnet.com [216.187.52.2]) by postgresql.org (Postfix) with ESMTP id 2069E9FB54C for ; Wed, 20 Jun 2007 03:45:30 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id l5K6jRHg022078 for ; Wed, 20 Jun 2007 02:45:27 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id l5K6jRJ4022075 for ; Wed, 20 Jun 2007 02:45:27 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Wed, 20 Jun 2007 02:45:27 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: pgsql-performance@postgresql.org Subject: Re: Volunteer to build a configuration tool In-Reply-To: <7621.1182318230@sss.pgh.pa.us> Message-ID: References: <1182298719.4482.133.camel@ipso.snappymail.ca> <7621.1182318230@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/404 X-Sequence-Number: 25437 On Wed, 20 Jun 2007, Tom Lane wrote: > I think what would be much more useful in the long run is some serious > study of the parameters themselves. For instance, random_page_cost is a > self-admitted oversimplification of reality. If I could figure out who would sponsor such a study that's what I'd be doing right now. I have studies on many of the commit-related parameters I'll have ready in another few days, those are straightforward to map out. But you know what I have never found? A good benchmark that demonstrates how well complicated queries perform to run studies on things like random_page_cost against. Many of the tuning knobs on the query optimizer seem very opaque to me so far, and I'm not sure how to put together a proper test to illuminate their operation and map out their useful range. Here's an example of one of the simplest questions in this area to demonstate things I wonder about. Let's say I have a properly indexed database of some moderate size such that you're in big trouble if you do a sequential scan. How can I tell if effective_cache_size is in the right ballpark so it will do what I want to effectively navigate that? People back into a setting for that parameter right now based on memory in their system, but I never see anybody going "since your main table is X GB large, and its index is Y GB, you really need enough memory to set effective_cache_size to Z GB if you want queries/joins on that table to perform well". -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD