Re: truncating pg_multixact/members
От | Alvaro Herrera |
---|---|
Тема | Re: truncating pg_multixact/members |
Дата | |
Msg-id | 20140120170450.GA10723@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: truncating pg_multixact/members (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: truncating pg_multixact/members
|
Список | pgsql-hackers |
Robert Haas escribió: > On Fri, Jan 3, 2014 at 9:11 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Yeah, this stuff is definitely underdocumented relative to vacuum right now. I have added a paragraph or two. It's a (probably insufficient) start. I would like to add a sample query to monitor usage, but I just realize we don't have a function such as age(xid) to expose this info usefully. We can't introduce one in 9.3 now, but probably we should do so in HEAD. > Also, while multixactid_freeze_min_age should be low, perhaps a > million as you suggest, multixactid_freeze_table_age should NOT be > lowered to 3 million or anything like it. If you do that, people who > are actually doing lots of row locking will start getting many more > full-table scans. We want to avoid that at all cost. I'd probably > make the default the same as for vacuum_freeze_table_age, so that > mxids only cause extra full-table scans if they're being used more > quickly than xids. I agree that the freeze_table limit should not be low, but 150 million seems too high. Not really sure what's a good value here. Here's a first cut at this. Note I have omitted a setting equivalent to autovacuum_freeze_max_age, but I think we should have one too. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: