Re: Re[2]: request for enhancement: 2K -> 4K

> The first DBMS I used was IBM's IMS I was using version 1.3 which was > written sometime in the early 80's or late 70's. You could use any > page size you wanted. > > Surely if the problem was solved once it could be solved again. Many of the earlier databases used this "variable page" format. However, this resulted in a major buffer fragmentation management problem. What they generally did was to create a linked list ordered by page size. When a buffer of a specific size was needed, the entire list had to be passed. Also this tended to make it difficult to find space for the larger pages. For instance suppose that some of the pages were 2K, some were 4K, and some were 8K. Now suppose that we had an 8K allocation at address 1000K. Now suppose that the engine needed a 2K buffer and the only place that could be found was at address 1000K. That would mean that the left over 6K would not be used and marked free. So maybe the next request was for an buffer of 4K and the system used the address of 1002K to store it. That would result in a 2K block in front of 1002K and a 3K free block at 1006K. The result would be that the buffer pool would be fragmented so that the 8K buffer couldn't be stored. On these systems, one of the common performance tuning tricks was to insist that all pages be the same size. On most systems by doing this would greatly improve pefromance, simply because the amount of time being spent in buffer management was minimized. I agree that the idea of using a 4K (or even 8K) page size has a possible performance advantage. From what I remember, this was done on all platforms of XPS. The problem is how to handle the existing customer base. Do we insist that the existing customer base migrate (i.e. unload/reload) their databases? Do we make the page size configurable, and increase the code path that this would cause? (If the page is configurable, we would have to check constantly what the page size is.) Madison Pruet