Re: priority on a process
От | Chris Palmer |
---|---|
Тема | Re: priority on a process |
Дата | |
Msg-id | 4DC5F5CE7BA89D40B26FFD9A7982FE25018DC6@mail.geneedinc.com обсуждение исходный текст |
Ответ на | priority on a process ("Johnson, Shaunn" <SJohnson6@bcbsm.com>) |
Ответы |
Re: priority on a process
|
Список | pgsql-general |
Scott Marlowe writes: > Yes, effective_cache_size is the postgresql setting that > tells the postmaster we have "about this much kernel cache" > on average. > > If it's set low, then postgresql assumes the kernel isn't > caching much, if it's higher, then it assumes it's more > likely for data to be "in memory" > and makes index scans more likely than seq scans. > > Sorry, I should have pointed out I was talking out about a > postgresql configuration parameter and not a linux one... Ahh. Thanks for the tip (I am still new to Pg). I guess the reason Pg can't ask the running kernel how much cache mem it has is that any such thing would be completely non-portable. Now branching the thread: The documentation (doc/runtime-config.html in my 7.3.2 source tree) says the value is a number of disk pages, and that disk pages are usualy 8KB. My filesystem has 4KB blocks; are blocks and pages the same thing in this context, or does "page" refer to the in-memory copy of a disk block? Are bigger blocks/pages on the filesystem used for Pg a good idea? I would guess yes, since Pg's data files are few and large, instead of many and small. Should I just crank my fs block size as big as it will go, on a partition dedicated to pg_data? Thanks.
В списке pgsql-general по дате отправления: