| From: | Richard Huxton <dev(at)archonet(dot)com> | 
|---|---|
| To: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> | 
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Storage Model for Partitioning | 
| Date: | 2008-01-11 11:57:42 | 
| Message-ID: | 478759B6.4080505@archonet.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Csaba Nagy | 2008-01-11 12:04:31 | Re: Storage Model for Partitioning | 
| Previous Message | Simon Riggs | 2008-01-11 11:49:50 | Re: Dynamic Partitioning using Segment Visibility Maps |