> > What are the odds of going through and revamping some of the > > tunables in postgresql.conf for the 7.4 release? I was just > > working with someone on IRC and on their 7800 RPM IDE drives, > > their random_page_cost was ideally suited to be 0.32: a far cry > > from 4. > > I find it very very hard to believe a random read was cheaper than a > sequential read. Something is shifty in your testing.
This is the procedure used to zero in on the number: SET random_page_cost = 3; [run query three times] SET random_page_cost = 2; [run query three times] SET random_page_cost = 1; [run query three times] SET random_page_cost = 0.01; -- verify that this tunable would make -- a difference eventually [run query three times] SET random_page_cost = 0.5; [run query three times] SET random_page_cost = 0.2; -- this was the 1st query that didn't -- do a seq scan [run query three times] SET random_page_cost = 0.4; -- back to a seq scan [run query three times] SET random_page_cost = 0.3; -- idx scan, how high can I push the rpc? [run query three times] SET random_page_cost = 0.35; -- interesting, the query time jumped to -- about 0.2s... better than 40s, but not as -- nice as the 0.25ms when the rpc was at 0.3 [run query three times] SET random_page_cost = 0.32; -- Sweet, 0.25ms for the query [run query three times] SET random_page_cost = 0.33; -- Bah, back up to 0.2s [run query three times] SET random_page_cost = 0.31; -- Down to 0.25ms, too low [run query three times] SET random_page_cost = 0.33; -- Double check that it wasn't an errant -- performance at 0.33 [run query three times] SET random_page_cost = 0.32; -- Double check that 0.32 is the magic number [run query three times] [edit postgresql.conf && killall -SIGHUP postmaster] -sc -- Sean Chittenden
pgp00000.pgp
Description: PGP signature