Thread: 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@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@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@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.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@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@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@familyhealth.com.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