Re: tracking commit timestamps

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Steve Singer <steve(at)ssinger(dot)info>, Andres Freund <andres(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>
Subject: Re: tracking commit timestamps
Date: 2014-11-11 20:03:44
Message-ID: 20141111200344.GT1791@alvin.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

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(at)alvh(dot)no-ip(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-11-11 20:11:16 Minor problem with comment added by 5ea86e
Previous Message Jim Nasby 2014-11-11 19:51:40 Re: tracking commit timestamps

Browse pgsql-www by date

  From Date Subject
Next Message Jim Nasby 2014-11-11 21:18:17 Re: tracking commit timestamps
Previous Message Jim Nasby 2014-11-11 19:51:40 Re: tracking commit timestamps