Re: Free Space Map thoughts

Simon Riggs wrote:
> On Thu, 2007-11-08 at 23:04 +0000, Gregory Stark wrote:
>> "Simon Riggs" <simon@2ndquadrant.com> writes:
>>
>>> The pages might well be in cache, so the file location might well be
>>> irrelevant from an I/O perspective. Maybe. The nth page solution allows
>>> the FSM block to be easily located without any FSM index, so might well
>>> be faster. Separate files mean more space and more fsyncs too. But even
>>> so, I'm not sure either way.
>> I don't follow any of the logical leaps in this paragraph. 
> 
> I asked Heikki to explain why he felt the design should go a certain
> way, which he didn't do. That's the logical leap I'm worried about.

Well, it's just intuition at this point.

Some points I did already mention:
- The locking is harder. At least the visibility map will require 
holding a lock on the heap page and the visibility map page at the same 
time.
- We need a solution for the indexes as well. A separate file would fit 
nicely for them, though the contents would be different because for 
indexes we only care if a page is unused or not.
- Using a separate file, the FSM pages will be closer together, which is 
good if you need to scan them.

On the other hand:
- Using more files requires more file handles
- Using every nth heap page requires no changes to catalog or buffer manager

Either way, you don't need any FSM index to locate a page.

I did consider other data structures as well, like a B-tree, keyed by 
block number. Or a heap, with page with most free space at the top. But 
a big problem with them is that as they are more complex, you need more 
care to make them crash-safe. And you might even need some kind of free 
space management for the FSM itself.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com