Re: multixacts woes

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: multixacts woes
Дата
Msg-id CA+TgmoazFk1bK2J92Do7Ee0cj28BC5zc-0vnQqMt_R=_rtzw0A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: multixacts woes  (Noah Misch <noah@leadboat.com>)
Ответы Re: multixacts woes  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Sun, May 10, 2015 at 1:40 PM, Noah Misch <noah@leadboat.com> wrote:
> I don't know whether this deserves prompt remediation, but if it does, I would
> look no further than the hard-coded 25% figure.  We permit users to operate
> close to XID wraparound design limits.  GUC maximums force an anti-wraparound
> vacuum at no later than 93.1% of design capacity.  XID assignment warns at
> 99.5%, then stops at 99.95%.  PostgreSQL mandates a larger cushion for
> pg_multixact/offsets, with anti-wraparound VACUUM by 46.6% and a stop at
> 50.0%.  Commit 53bb309d2d5a9432d2602c93ed18e58bd2924e15 introduced the
> bulkiest mandatory cushion yet, an anti-wraparound vacuum when
> pg_multixact/members is just 25% full.

That's certainly one possible approach.  I had discounted it because
you can't really get more than a small multiple out of it, but getting
2-3x more room might indeed be enough to help some people quite a bit.
Just raising the threshold from 25% to say 40% would buy back a
healthy amount.

Or, as you suggest, we could just add a GUC.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Manipulating complex types as non-contiguous structures in-memory
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)