Re: Rewriting Free Space Map

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)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!