I'm not saying those ideas don't have problems, because they do. But I think they are worth further exploring. The main reason I gave up on that is because Heikki was working on the XID-to-LSN mapping stuff. That seemed like a better approach than either of the above, so as long as Heikki was working on that, there wasn't much reason to pursue more lowbrow approaches. Clearly, though, we need to do something about this. Freezing is a big problem for lots of users.
All that having been said, I don't think adding a new fork is a good approach. We already have problems pretty commonly where our customers complain about running out of inodes. Adding another fork for every table would exacerbate that problem considerably.
We were talking about having an incremental backup map also. Which sounds a lot like the freeze map.
XID-to-LSN sounded cool but was complex. If we need the map for backup purposes, we may as well do it the simple way and hit both birds at once.
We only need a freeze/backup map for larger relations. So if we map 1000 blocks per map page, we skip having a map at all when size < 1000.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
