On Fri, 2008-01-04 at 10:22 +0000, Richard Huxton wrote: > Simon Riggs wrote: > > We would keep a dynamic visibility map at *segment* level, showing which > > segments have all rows as 100% visible. No freespace map data would be > > held at this level. > > Small dumb-user question. > > I take it you've considered some more flexible consecutive-run-of-blocks > unit of flagging rather than file-segments. That obviously complicates > the tracking but means you can cope with infrequent updates as well as > mark most of the "most recent" segment for log-style tables.
I'm writing the code to abstract that away, so yes. Now you mention it, it does seem straightforward to have a table storage parameter for partition size, which defaults to 1GB. The partition size is simply a number of consecutive blocks, as you say. The smaller the partition size the greater the overhead of managing it. Also I've been looking at read-only tables and compression, as you may know. My idea was that in the future we could mark segments as either - read-only - compressed - able to be shipped off to hierarchical storage Those ideas work best if the partitioning is based around the physical file sizes we use for segments. Changing the partition size would simply reset the visibility map for that table, in its easiest implementation. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
