Re: Rewriting Free Space Map

Gregory Stark wrote:
> "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.
>
>   

Why can't you just do that with a different extension and file rename? 
You'd need an exclusive lock while swapping in the new map, but you need 
that anyway, IIRC, and this way you don't even need a catalog change.

cheers

andrew