On 3/3/2016 11:43 AM, Vlad Khorsun wrote: > 03.03.2016 17:57, Jim Starkey wrote: >> The place to start is with a clear, well understood, and agreed set of >> requirements. Here is a suggested starting point. >> >> First, some definitions. A "data space" is the collection of pointer and >> data pages that hold the data from a single table. An >> "index" (in this context), is the set of index pages that compromise a >> single index on a table. A "database object" is either a >> data space or an index. A "table space" consists of a page structured file, >> a collection of management pages, and a page number >> space that can hold zero or more database objects. >> >> The minimal requirements: >> >> 1. To extend the theoretical number of database pages in a database beyond >> 2^32. >> 2. To be as inobstrusive as possible so that no explicit configuration is >> required for databases that don't use table spaces. In >> other words, a default (root) table space. >> 3. To allow a user to define and manage additional table spaces. >> 4. To allow a user to define tables spaces for individual tables and >> individual indexes. In other words, while indexes may default >> to the same table space of the table data space, indexes may reside in >> different table spaces. >> 5. A user should be able to move a table data space or index from one >> table space to another. Whether this is an on-line or >> off-line operation is deferred to specific proposals. >> 6. It should be possible to bring up a database with some or all table >> spaces unavailable other than the root. >> 7. A table space should have sufficient internal integrity to tolerate >> operational problems resulting improper management of >> database files. >> 8. It must be necessary to allow the filename of an offline table space to >> be changed. > Basically, i agree with above. > >> Personally, I think the following are also important, but not requirements: >> >> 1. There should be minimal changes to the on-disk structure. More >> specifically, pages references in the ODS should remain as 32 >> bits. This precludes allowing a database object to straggle table >> spaces. >> 2. There should be as few changes as possible to internal page, index, and >> data handling mechanism other than tracking the table >> space for database objects for the CCH interface. >> 3. It should be anticipated that table spaces will be abused, for example >> replacing table space files with older versions. To the >> degree feasible, this should be supported, and where not supported, >> detected. > I would add > > 4. Allow to specify FW and Read-Only settings on per tablespace level > 5. Ability to bring individual tablespace off-line (and back online, of > course)
#5 is a candidate for promotion to a requirement, but keep in mind that some mechanism must be invented to sweep any off-line table spaces before they come on-line lest record versions created by abandoned or rolled back transactions suddenly re-appear. This should be reasonably straightforward as the TIPs have retain the old states. > >> Non-goals: >> >> 1. Change the size of record numbers >> 2. Store blobs in other than the table's data space. > Why not allow blobs to be separated from regular data ? OK, reasonable question. Obviously they could, but it would require either storing small blobs off page or changing the mechanism used for blob ids, or both. It also runs the risk of the records and blobs diverging, which is very, very bad. I think the benefit of separating records and blobs is quite limited. Large blobs have at least their rear end stored on blob pages that aren't scanned for exhaustive retrievals. Moving them to a separate data space within the same table space so they don't share the record number space with records is well worth considering. > >> 3. Implement any ODS change other than those required to support table >> spaces (other projects are fine, but should be layered on, >> not part of, table spaces). > Regards, > Vlad > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
