Re: PostgreSQL caching
От | Rosser Schwarz |
---|---|
Тема | Re: PostgreSQL caching |
Дата | |
Msg-id | 002801c43f48$6d629930$2500fa0a@CardServices.TCI.com обсуждение исходный текст |
Ответ на | PostgreSQL caching (Vitaly Belman <vitalib@012.net.il>) |
Ответы |
Re: PostgreSQL caching
|
Список | pgsql-performance |
while you weren't looking, Vitaly Belman wrote: > So, I guess it has to do with PostgreSQL caching.. But how exactly > does it work? What does it cache? And how can I control it? PostgreSQL uses the operating system's disk cache. You can hint to the postmaster how much memory is available for caching with the effective_cache_size directive in your postgresql.conf. If you're running a *nix OS, you can find this by watching `top` for a while; in the header, there's a "cached" value (or something to that effect). Watching this value, you can determine a rough average and set your effective_cache_size to that rough average, or perhaps slightly less. I'm not sure how to get this value on Windows. Pgsql uses the OS's disk cache instead of its own cache management because the former is more likely to persist. If the postmaster managed the cache, as soon as the last connection died, the memory allocated for caching would be released, and all the cached data would be lost. Relying instead on the OS to cache data means that, whether or not there's a postmaster, so long as there has been one, there'll be some data cached. You can "prepopulate" the OS disk cache by periodically running a handful of SELECT queries that pull from your most commonly accessed tables in a background process. (A good way of doing that is simply to run your most commonly executed SELECTS.) Those queries should take the performance hit of fetching from disk, while your regular queries hit the cache. /rls -- Rosser Schwarz Total Card, Inc.
В списке pgsql-performance по дате отправления: