On Fri, Sep 9, 2011 at 3:16 PM, Kevin Grittner <Kevin.Grittner@xxxxxxxxxxxx> wrote: > Add together the shared_buffers setting and whatever the OS tells > you is used for cache under your normal load. It's usually 75% of > RM or higher. (NOTE: This doesn't cause any allocation of RAM; it's > a hint to the cost calculations.) In the manual[0] it says to take into account the number of concurrent access to different indices and tables: " Sets the planner's assumption about the effective size of the disk cache that is available to a single query. This is factored into estimates of the cost of using an index; a higher value makes it more likely index scans will be used, a lower value makes it more likely sequential scans will be used. When setting this parameter you should consider both PostgreSQL's shared buffers and the portion of the kernel's disk cache that will be used for PostgreSQL data files. Also, take into account the expected number of concurrent queries on different tables, since they will have to share the available space. This parameter has no effect on the size of shared memory allocated by PostgreSQL, nor does it reserve kernel disk cache; it is used only for estimation purposes. The default is 128 megabytes (128MB). " However, every mail I've seen on the list, and every bibliography seems to ignore that. Does PG consider it automatically now, and admins only have to input the amount of system memory? (in which case PG could autoconfigure itself by querying /proc), is the manual wrong, or is the advise given everywher just ignoring that bit? [0] http://www.postgresql.org/docs/9.0/static/runtime-config-query.html -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
