Re: Script to compute randon page cost

Linux RedHat 7.3 (ext3, kernel 2.4.18-3)
512MB Ram
AMD Athlon 500
IBM 120GB IDE

[hs(at)backup hs]$ ./randcost.sh /data/db/
Collecting sizing information ...
Running random access timing test ...
Running sequential access timing test ...

random_page_cost = 0.901961

[hs(at)backup hs]$ ./randcost.sh /data/db/
Collecting sizing information ...
Running random access timing test ...
Running sequential access timing test ...

random_page_cost = 0.901961

Great script - it should be in contrib.

Hans

--
*Cybertec Geschwinde u Schoenig*
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/1/913 68 09; +43/664/233 90 75
www.postgresql.at <http://www.postgresql.at>, cluster.postgresql.at
<http://cluster.postgresql.at>, www.cybertec.at
<http://www.cybertec.at>, kernel.cybertec.at <http://kernel.cybertec.at>

Assuming it's giving out correct information, there seems to be a lot of
evidence for dropping the default random_page_cost to 1...

Chris

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Hans-Jürgen
> Schönig
> Sent: Monday, 9 September 2002 4:06 PM
> To: pgsql-hackers
> Subject: [HACKERS] Script to compute randon page cost
>
>
> Linux RedHat 7.3 (ext3, kernel 2.4.18-3)
> 512MB Ram
> AMD Athlon 500
> IBM 120GB IDE
>
>
> [hs(at)backup hs]$ ./randcost.sh /data/db/
> Collecting sizing information ...
> Running random access timing test ...
> Running sequential access timing test ...
>
> random_page_cost = 0.901961
>
>
>
> [hs(at)backup hs]$ ./randcost.sh /data/db/
> Collecting sizing information ...
> Running random access timing test ...
> Running sequential access timing test ...
>
> random_page_cost = 0.901961
>
>
> Great script - it should be in contrib.
>
> Hans
>
>
>
> --
> *Cybertec Geschwinde u Schoenig*
> Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
> Tel: +43/1/913 68 09; +43/664/233 90 75
> www.postgresql.at <http://www.postgresql.at>, cluster.postgresql.at
> <http://cluster.postgresql.at>, www.cybertec.at
> <http://www.cybertec.at>, kernel.cybertec.at <http://kernel.cybertec.at>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

Christopher Kings-Lynne wrote:

>Assuming it's giving out correct information, there seems to be a lot of
>evidence for dropping the default random_page_cost to 1...
>
>Chris
>
>
Some time ago Joe Conway suggest a tool based on a genetic algorithm
which tries to find the best parameter settings.
As input the user could use a set of SQL statements. The algorithm will
try to find those settings which lead to the lowest execution time based
on the set of SQL.

What about something like that?
This way people could tune the database theirselves.

Hans

--
*Cybertec Geschwinde u Schoenig*
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/1/913 68 09; +43/664/233 90 75
www.postgresql.at <http://www.postgresql.at>, cluster.postgresql.at
<http://cluster.postgresql.at>, www.cybertec.at
<http://www.cybertec.at>, kernel.cybertec.at <http://kernel.cybertec.at>

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> Assuming it's giving out correct information, there seems to be a lot of
> evidence for dropping the default random_page_cost to 1...

The fact that a lot of people are reporting numbers below 1 is
sufficient evidence that the script is broken. A value below 1
is physically impossible.

regards, tom lane

On Mon, 2002-09-09 at 01:16, Hans-Jürgen Schönig wrote:
> Christopher Kings-Lynne wrote:
>
> >Assuming it's giving out correct information, there seems to be a lot of
> >evidence for dropping the default random_page_cost to 1...
> >
> >Chris
> >
> >
> Some time ago Joe Conway suggest a tool based on a genetic algorithm
> which tries to find the best parameter settings.
> As input the user could use a set of SQL statements. The algorithm will
> try to find those settings which lead to the lowest execution time based
> on the set of SQL.
>
> What about something like that?
> This way people could tune the database theirselves.
>

I actually had starting coding a tool like this, but have become
distracted with other things. I plan on continuing with it maybe next
week. If anyone has suggestions, please let me know...

--brett

--
Brett Schwarz
brett_schwarz AT yahoo.com