> > 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
