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)?
|
Список | 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 по дате отправления: