Simon Riggs wrote:
> The smaller the partition size the greater the overhead of managing it.
> Also I've been looking at read-only tables and compression, as you may
> know. My idea was that in the future we could mark segments as either
> - read-only
> - compressed
> - able to be shipped off to hierarchical storage
> Those ideas work best if the partitioning is based around the physical
> file sizes we use for segments.
As much as I'd like this simplification.. But I'm still thinking of
these segments as an implementation detail of Postgres, and not
something the user should have to deal with.
Allowing the DBA to move segments to a different table space and giving
him the possibility to check which tuples are in which segment seems
awkward from a users perspective, IMO.
In response to
pgsql-hackers by date
|Next:||From: Glyn Astill||Date: 2008-01-04 13:23:18|
|Subject: Problem with PgTcl auditing function on trigger|
|Previous:||From: Markus Schiltknecht||Date: 2008-01-04 12:39:42|
|Subject: Re: Dynamic Partitioning using Segment Visibility Maps|