Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?
Дата
Msg-id 54D029E0.7000800@BlueTreble.com
обсуждение исходный текст
Ответ на Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?  (Slava Mudry <slava44@gmail.com>)
Список pgsql-performance
On 2/2/15 7:36 PM, Jim Nasby wrote:
>>
>> Currently the fact that it needs to go back to old tables and FTS them
>> every 2B transactions (or rely on autovacuum for this) and you can't do
>> anything about it (like permanently freeze the tables) seems like a big
>> scalability issue. Does it not?
>
> Unfortunately it's not terribly easy to fix this. The problem is if we
> try to play games here, we must have a 100% reliable method for changing
> relfrozenxid as soon as someone inserts a new tuple in the relation. It
> might be possible to tie this into the visibility map, but no one has
> looked at this yet.
>
> Perhaps you'd be willing to investigate this, or sponsor the work?

Oh, there is another possibility that's been discussed: read-only
tables. If we had the ability to mark a table read-only, then a VACUUM
FREEZE on such a table would be able to set that table's relfrozenxid to
FrozenTransactionId and prevent any further attempts at vacuuming. This
might be easier than trying to do something automatic.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: working around JSONB's lack of stats?
Следующее
От: Slava Mudry
Дата:
Сообщение: Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?