Re: tracking commit timestamps

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: tracking commit timestamps
Дата
Msg-id 546268CC.7010507@BlueTreble.com
обсуждение исходный текст
Ответ на Re: tracking commit timestamps  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: tracking commit timestamps  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On 11/10/14, 7:40 AM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Sun, Nov 9, 2014 at 8:41 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>>> Robert Haas wrote:
>>>> I think the key question here is the time for which the data needs to
>>>> be retained.  2^32 of anything is a lot, but why keep around that
>>>> number of records rather than more (after all, we have epochs to
>>>> distinguish one use of a given txid from another) or fewer?
>>>
>>> The problem is not how much data we retain; is about how much data we
>>> can address.
>>
>> I thought I was responding to a concern about disk space utilization.
>
> 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)
onlyhappen 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.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Column/type dependency recording inconsistencies
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: tracking commit timestamps