Re: Auto-tuning work_mem and maintenance_work_mem
От | MauMau |
---|---|
Тема | Re: Auto-tuning work_mem and maintenance_work_mem |
Дата | |
Msg-id | E21223D1C5034BF7BA20DAB5A69BC8F0@maumau обсуждение исходный текст |
Ответ на | Re: Auto-tuning work_mem and maintenance_work_mem (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Auto-tuning work_mem and maintenance_work_mem
|
Список | pgsql-hackers |
From: "Bruce Momjian" <bruce@momjian.us> > On Thu, Oct 10, 2013 at 11:01:52PM +0900, MauMau wrote: >> Although this is not directly related to memory, could you set >> max_prepared_transactions = max_connections at initdb time? People >> must feel frustrated when they can't run applications on a Java or >> .NET application server and notice that they have to set >> max_prepared_transactions and restart PostgreSQL. This is far from >> friendly. > > I think the problem is that many users don't need prepared transactions > and therefore don't want the overhead. Is that still accurate? I'm not sure if many use XA features, but I saw the questions and answer a few times, IIRC. In the trouble situation, PostgreSQL outputs an intuitive message like "increase max_prepared_transactions", so many users might possibly have been able to change the setting and solve the problem themselves without asking for help, feeling stress like "Why do I have to set this?" For example, max_prepared_transactions is called "hideous creature" in the following page: https://community.jboss.org/wiki/InstallPostgreSQLOnFedora?_sscc=t According to the below page, the amount of memory consumed for this is "(770 + 270 * max_locks_per_transaction) * max_prepared_transactions". With the default setting of maxconnections=100 and max_locks_per_transaction=64, this is only 180KB. So the overhead is negligible. http://www.postgresql.org/docs/9.2/static/kernel-resources.html If the goal is to make PostgreSQL more friendly and run smoothly without frustration from the start and not perfect tuning, I think max_prepared_transactions=max_connections is an easy and good item. If the goal is limited to auto-tuning memory sizes, this improvement can be treated separately. Regards MauMau
В списке pgsql-hackers по дате отправления: