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
