Re: multixacts woes
От
Alvaro Herrera
Тема
Re: multixacts woes
Дата
Msg-id
20150511174109.GU2523@alvh.no-ip.org
Ответ на
Re: multixacts woes (Josh Berkus)
Список
Дерево обсуждения
multixacts woes Robert Haas <robertmhaas@gmail.com>
Re: multixacts woes andres@anarazel.de (Andres Freund)
Re: multixacts woes Robert Haas <robertmhaas@gmail.com>
Re: multixacts woes Andres Freund <andres@anarazel.de>
Re: multixacts woes Alvaro Herrera <alvherre@2ndquadrant.com>
Re: multixacts woes Robert Haas <robertmhaas@gmail.com>
Re: multixacts woes Andrew Dunstan <andrew@dunslane.net>
Re: multixacts woes Noah Misch <noah@leadboat.com>
Re: multixacts woes Robert Haas <robertmhaas@gmail.com>
Re: multixacts woes Noah Misch <noah@leadboat.com>
Re: multixacts woes Robert Haas <robertmhaas@gmail.com>
Re: multixacts woes Noah Misch <noah@leadboat.com>
Re: multixacts woes Robert Haas <robertmhaas@gmail.com>
Re: multixacts woes Alvaro Herrera <alvherre@2ndquadrant.com>
Re: multixacts woes Jim Nasby <Jim.Nasby@BlueTreble.com>
Josh Berkus wrote: > In terms of adding a new GUC in 9.5: can't we take a stab at auto-tuning > this instead of adding a new GUC? We already have a bunch of freezing > GUCs which fewer than 1% of our user base has any idea how to set. If you have development resources to pour onto 9.5, I think it would be better spent changing multixact usage tracking so that oldestOffset is included in pg_control; also make pg_multixact truncation be WAL-logged. With those changes, the need for a lot of pretty complicated code would go away. The fact that truncation is done by both vacuum and checkpoint causes a lot of the mess we were in (and from which Robert and Thomas took us --- thanks guys!). Such a change is the first step towards auto-tuning, I think. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления