Re: Rewriting Free Space Map
От | Gregory Stark |
---|---|
Тема | Re: Rewriting Free Space Map |
Дата | |
Msg-id | 873aqpcomp.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Rewriting Free Space Map (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Rewriting Free Space Map
Re: Rewriting Free Space Map |
Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > "Heikki Linnakangas" <heikki@enterprisedb.com> 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!
В списке pgsql-hackers по дате отправления: