Re: planner with index scan cost way off actual cost,
От | Mark Kirkwood |
---|---|
Тема | Re: planner with index scan cost way off actual cost, |
Дата | |
Msg-id | 441FD82D.1040509@paradise.net.nz обсуждение исходный текст |
Ответ на | Re: planner with index scan cost way off actual cost, advices to tweak cost constants? ("Jim C. Nasby" <jnasby@pervasive.com>) |
Ответы |
Re: planner with index scan cost way off actual cost,
|
Список | pgsql-performance |
Jim C. Nasby wrote: > On Mon, Mar 20, 2006 at 09:35:14AM +0100, Guillaume Cottenceau wrote: > >>>shared_buffer = 12000 >>>effective_cache_size = 25000 >>> >>>This would mean you are reserving 100M for Postgres to cache relation >>>pages, and informing the planner that it can expect ~200M available >>>from the disk buffer cache. To give a better recommendation, we need >> >>Ok, thanks. I wanted to investigate this field, but as the >>application is multithreaded and uses a lot of postgres clients, >>I wanted to make sure the shared_buffers values is globally for >>postgres, not just per (TCP) connection to postgres, before >>increasing the value, fearing to take the whole server down. > > > shared_buffer is for the entire 'cluster', not per-connection or > per-database. > > Also, effective_cache_size of 25000 on a 1G machine seems pretty > conservative to me. I'd set it to at least 512MB, if not closer to > 800MB. I was going to recommend higher - but not knowing what else was running, kept it to quite conservative :-)... and given he's running java, the JVM could easily eat 512M all by itself! Cheers Mark
В списке pgsql-performance по дате отправления: