Re: tracking commit timestamps

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: tracking commit timestamps
Дата
Msg-id 20141111200344.GT1791@alvin.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: tracking commit timestamps  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: tracking commit timestamps  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
Jim Nasby wrote:
> On 11/10/14, 7:40 AM, Alvaro Herrera wrote:

> >Ah, right.  So AFAIK we don't need to keep anything older than
> >RecentXmin or something like that -- which is not too old.  If I recall
> >correctly Josh Berkus was saying in a thread about pg_multixact that it
> >used about 128kB or so in <= 9.2 for his customers; that one was also
> >limited to RecentXmin AFAIR.  I think a similar volume of commit_ts data
> >would be pretty acceptable.  Moreso considering that it's turned off by
> >default.
> 
> FWIW, AFAICS MultiXacts are only truncated after a (auto)vacuum process is able to advance datminmxid, which will
(now)only happen when an entire relation has been scanned (which should be infrequent).
 
> 
> I believe the low normal space usage is just an indication that most databases don't use many MultiXacts.

That's in 9.3.  Prior to that, they were truncated much more often.
Maybe you've not heard enough about this commit:

commit 0ac5ad5134f2769ccbaefec73844f8504c4d6182
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date:   Wed Jan 23 12:04:59 2013 -0300
   Improve concurrency of foreign key locking

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: tracking commit timestamps
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Minor problem with comment added by 5ea86e