Re: Storage Model for Partitioning
От | Richard Huxton |
---|---|
Тема | Re: Storage Model for Partitioning |
Дата | |
Msg-id | 478759B6.4080505@archonet.com обсуждение исходный текст |
Ответ на | Re: Storage Model for Partitioning (Csaba Nagy <nagy@ecircle-ag.com>) |
Ответы |
Re: Storage Model for Partitioning
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: