>>> On Thu, Oct 4, 2007 at 10:28 AM, in message
<20071004102804.3418912e@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Josh Trutwin
<josh@xxxxxxxxxxxxxxxxxxx> wrote:
> running postgres 8.1.4
> # cat /proc/meminfo
> total: used: free: shared: buffers: cached:
> Mem: 3704217600 3592069120 112148480 0 39460864 2316271616
> shared_buffers = 16384 (was 1000)
> effective_cache_size = 10000 (was 1000)
It's kind of silly to tell PostgreSQL that its total cache space is 10000
pages when you've got more than that in shared buffers plus all that OS
cache space. Try something around 285000 pages for effective_cache_size.
> stats_command_string = on (was off)
> stats_block_level = on (was off)
> stats_row_level = on (was off)
> After making these changes, the performance on the server actually
> worsened. I slowly backed off on some of the paramaters but didn't
> seem to help.
Did you try turning off the collection of those additional statistics?
That isn't free.
You didn't get specific about what you saw in performance problems. If
you are seeing occasional "freezes" of all queries, you are likely looking
at a known issue with "spikiness" of disk output. For some this can be
corrected by using very aggressive background writer settings. Some have
solved it by disabling OS write delays. Some haven't found a solution and
are waiting for 8.3; there have been some serious changes made to attempt
to resolve this issue.
-Kevin
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
