Hash: SHA1

> Your argument seems to be "this produces nice results for me", not
> "I have done experiments to measure the actual value of the parameter
> and it is X".  I *have* done experiments of that sort, which is where
> the default of 4 came from.  I remain of the opinion that reducing
> random_page_cost is a band-aid that compensates (but only partially)
> for problems elsewhere.  We can see that it's not a real fix from
> the not-infrequent report that people have to reduce random_page_cost
> below 1.0 to get results anywhere near local reality.  That doesn't say
> that the parameter value is wrong, it says that the model it's feeding
> into is wrong.

Good points: allow me to rephrase my question then:

When I install a new version of PostgreSQL and start testing my
applications, one of the most common problems is that many of my queries
are not hitting an index. I typically drop random_page_cost to 2 or
lower and this speeds things very significantly. How can I determine a
better way to speed up my queries, and why would this be advantageous
over simply dropping random_page_cost? How can I use my particular
situation to help develop a better model and perhaps make the defaults
work better for my queries and other people with databaes like mine.
(fairly simple schema, not too large (~2 Gig total), SCSI, medium to
high complexity queries, good amount of RAM available)?

- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200503150600



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to