2011/1/12 Kevin Grittner <Kevin.Grittner@wicourts.gov>:
> Laszlo Nagy <gandalf@shopzeus.com> wrote:
>
>>> In addition to the good advice from Ken, I suggest that you set
>>> effective_cache_size (if you haven't already). Add whatever the
>>> OS shows as RAM used for cache to the shared_mem setting.
>> It was 1GB. Now I changed to 2GB. Although the OS shows 9GB
>> inactive memory, we have many concurrent connections to the
>> database server. I hope it is okay to use 2GB.
>
> effective_cache_size doesn't cause any RAM to be allocated, it's
> just a hint to the costing routines. Higher values tend to favor
> index use, while lower values tend to favor sequential scans. I
> suppose that if you regularly have many large queries running at the
> same moment you might not want to set it to the full amount of cache
> space available,
> but I've usually had good luck setting to the sum
> of shared_buffers space and OS cache.
What is the OS used ? Do you have windows ? if yes the current
parameters are not good, and linux should not have 9GB of 'inactive'
(?) memory.
>
> Since it only affects plan choice, not memory allocations, changing
> it won't help if good plans are already being chosen.
>
> -Kevin
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support