Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)
От | Kevin Grittner |
---|---|
Тема | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Дата | |
Msg-id | 789650107.1373029.1430772107036.JavaMail.yahoo@mail.yahoo.com обсуждение исходный текст |
Ответ на | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: BUG #12990: Missing pg_multixact/members files
(appears to have wrapped, then truncated)
|
Список | pgsql-bugs |
Robert Haas <robertmhaas@gmail.com> wrote: > 1. Using a min freeze age of zero will result in half as many > full-table scans, because we'll advance relminmxid twice as far > each time. > > 2. But each one will freeze more stuff, some of which might have > been updated again before the next freeze pass, so we might do > more freezing in total. > > So either policy might win, depending on whether you care more > about reducing reads (in which case you want a very low min > freeze age) or about reducing writes (in which case you want a > higher min freeze age). > > All things being equal, I'd rather stick with the existing 50% > policy in the back-branches, rather than going to zero, but I'm > not sure all things are equal. It matters what difference the > higher value makes. I really don't like the "honor the configured value of vacuum_multixact_freeze_min_age until the members SLRU gets to 50% of wraparound and then use zero" approach. It made a lot more sense to me to honor the configured value to 25% and decrease it in a linear fashion until it hit zero at 75%. It seems like maybe we weren't aggressive enough in the dynamic adjustment of autovacuum_multixact_freeze_max_age, but I'm not clear why fixing that required the less gradual adjustment of the *_min_age setting. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: