Re: Free Space Map thoughts
От | Heikki Linnakangas |
---|---|
Тема | Re: Free Space Map thoughts |
Дата | |
Msg-id | 47342ADC.6010305@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Free Space Map thoughts (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Free Space Map thoughts
Re: Free Space Map thoughts |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: