Re: Automagic tuning - Mailing list pgsql-performance

From Tom Lane
Subject Re: Automagic tuning
Date
Msg-id 10114.1107234387@sss.pgh.pa.us
Whole thread Raw
In response to Re: Automagic tuning  ("Jim C. Nasby" <decibel@decibel.org>)
Responses Re: Automagic tuning  ("Jim C. Nasby" <decibel@decibel.org>)
List pgsql-performance
"Jim C. Nasby" <decibel@decibel.org> writes:
> On Mon, Jan 31, 2005 at 03:26:12PM -0500, Tom Lane wrote:
>> Preferably a whole lot of queries.  All the measurement techniques I can
>> think of are going to have a great deal of noise, so you shouldn't
>> twiddle these cost settings based on just a few examples.

> Are there any examples of how you can take numbers from pg_stats_* or
> explain analize and turn them into configuration settings (such and
> random page cost)?

Well, the basic idea is to adjust random_page_cost so that the ratio of
estimated cost to real elapsed time (as shown by EXPLAIN ANALYZE) is the
same for seqscans and indexscans.  What you have to watch out for is
that the estimated cost model is oversimplified and doesn't take into
account a lot of real-world factors, such as the activity of other
concurrent processes.  The reason for needing a whole lot of tests is
essentially to try to average out the effects of those unmodeled
factors, so that you have a number that makes sense within the planner's
limited view of reality.

            regards, tom lane

pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: High end server and storage for a PostgreSQL OLTP system
Next
From: Tom Lane
Date:
Subject: Re: Index Slowing Insert >50x