Simon Riggs wrote:
On Fri, 2008-01-11 at 11:34 +, Richard Huxton wrote:
Is the following basically the same as option #3 (multiple RelFileNodes)?
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
On Fri, 2008-01-11 at 11:34 +, Richard Huxton wrote:
> Is the following basically the same as option #3 (multiple RelFileNodes)?
>
> 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)
> 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
Csaba Nagy wrote:
On Fri, 2008-01-11 at 11:34 +, 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
On Fri, 2008-01-11 at 11:34 +, 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 a
More dumb user questions...
Simon Riggs wrote:
1. Partitions are Contiguous Ranges of Blocks
Partitions are a simple subset of a table, i.e. a contiguous range of
blocks within the main block range of the table.
b) Fixed partitioning - we define partitions as static ranges of blocks,
which m
>
> 3. Partitions are RelFileNodes, but not Tables
>
> We allow a table to have multiple RelFileNodes, when explicitly declared
> that way.
>
> This means we have to change
> - DDL changes to allow TABLE level changes to apply to all RelFileNodes,
> while PARTITION level changes to apply to only on
In my striving towards more effective partitioning for Postgres, I see
we have one main decision to make and that all other sub-tasks are
driven directly by this one issue. The issue is: At what point we store
the data within the existing storage model? We discussed this in 2005
when I started to d
