"Tom Lane" <[EMAIL PROTECTED]> writes: > "Heikki Linnakangas" <[EMAIL PROTECTED]> writes: >> My original thought was to have a separate RelFileNode for each of the >> maps. That would require no smgr or xlog changes, and not very many >> changes in the buffer manager, though I guess you'd more catalog >> changes. You had doubts about that on the previous thread >> (http://archives.postgresql.org/pgsql-hackers/2007-11/msg00204.php), but >> the "map forks" idea certainly seems much more invasive than that. > > The main problems with that are (a) the need to expose every type of map > in pg_class and (b) the need to pass all those relfilenode numbers down > to pretty low levels of the system. The nice thing about the fork idea > is that you don't need any added info to uniquely identify what relation > you're working on. The fork numbers would be hard-wired into whatever > code needed to know about particular forks. (Of course, these same > advantages apply to using special space in an existing file. I'm > just suggesting that we can keep these advantages without buying into > the restrictions that special space would have.)
One advantage of using separate relfilenodes would be that if we need to regenerate a map we could do it in a new relfilenode and swap it in like we do with heap rewrites. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
