On Wed, 2008-01-09 at 18:04 +0100, Markus Schiltknecht wrote:
> > So not convinced of the need for named sections of tables yet. It all
> > seems like detail, rather than actually what we want for managing large
> > tables.
>
> What do you think about letting the database system know the split point
> vs it having to find optimal split points automatically?
For me, managing the table's files can be separate from the chunking
that allows partition exclusion.
Managing the table's files must be a manual operation. We can't infer
the presence of a new tablespace etc.. Those files would need less than
10 zones or chunks, usually just one.
The chunking to allow partition exclusion can still be automatic,
allowing a much finer grain of partition.
If we restrict the actions allowed to be just
- mark read-only
then for read-only segments (only)
- migrate tablespaces
- compress read-only segments
- mark as off-line (not fully convinced we need this yet)
then it seems straightforward to allow this to occur by a WHERE clause
only, since the constraints on a segment will be fixed in place when it
is read-only. This also allows those operations to take place without
holding locks for any length of time, since they are all just metadata
ops or copying read only data to another place.
The WHERE clause approach might easily allow more than 2 chunks and they
need not be logically contiguous. So the phrase split point doesn't
really fit because it implies a one dimensional viewpoint, but I'm happy
for you to give it a name.
If we want to perform manipulations on non-read-only chunks then we need
named or numbered partitions, locking, DDL etc.. That seems like too
much functionality for what we really need. I really am still open on
that point, but I would like to see a good description of a use case
that really needs it, rather than just saying "of course we do". Which
is exactly where *I* started, even as recently as 3 weeks ago now.
-- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com