From: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
---|---|
To: | Richard Huxton <dev(at)archonet(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 12:04:31 |
Message-ID: | 1200053071.7528.53.camel@PCD12478 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
But why not have it as a normal index of ranges ? I'm not familiar with
the GIST extensions, but this sounds like a set of records (segments in
Simon's terms) indexed by their interval position on a line... isn't
that covered by some GIST index type ?
> 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?
That could be covered by something like the bitmap scan, just on coarser
level, the bits covering segments instead of blocks.
Cheers,
Csaba.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-01-11 12:15:46 | Re: Storage Model for Partitioning |
Previous Message | Richard Huxton | 2008-01-11 11:57:42 | Re: Storage Model for Partitioning |