Csaba Nagy wrote:
On Fri, 2008-01-11 at 11:34 +0000, Richard Huxton wrote:
1. Make an on-disk "chunk" much smaller (e.g. 64MB). Each chunk is a
contigous range of blocks.
2. Make a table-partition (implied or explicit constraints) map to
multiple "chunks".
That would reduce fragmentation (you'd have on average 32MB's worth of
blocks wasted per partition) and allow for stretchy partitions at the
cost of an extra layer of indirection.
This sounds almost like some kind of "clustering index", where the index
contains ranges pointing to blocks of data... if the same index is also
used for inserting (i.e. the free space map is a partial "cluster index"
on blocks with free space), that would be a coarse clustering solution I
guess...
Which is roughly what Simon's original "Dynamic Partitioning" would be
if it became visible at the planner level (unless I've misunderstood). I
was picturing it in my head as a two-dimensional bitmap with
value-ranges along one axis and block-ranges along the other. Of course,
unlike other indexes it needs visibility information to be of any use.
Thinking about it, I'm not sure how my thinking would affect a
full-table seq-scan. You'd not get blocks back in-order throughout the
scan - would that matter?
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
