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