Simon Riggs wrote:
On Thu, 2007-11-08 at 23:04 +0000, Gregory Stark wrote:
"Simon Riggs" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
