Hi,
Simon Riggs wrote:
> On Wed, 2008-01-09 at 18:04 +0100, Markus Schiltknecht wrote:
>> 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.
Agreed.
So in your terms, my question is: who does the chunking? What you are
proposing with SE is that the database does the chunking automatically
(based on spontaneous ordering). That's a novel and interesting idea to me.
> Managing the table's files must be a manual operation. We can't infer
> the presence of a new tablespace etc..
Sure.
However, letting the database do the chunking (i.e. define split
points), but leaving it up to the user to decide where to put those
chunks certainly doesn't work.
So, there are only two options: either we let the user choose split
points manually, or else we tell the database those missing pieces of
information and rely on automatisms.
If I understand correctly, you are stating, that in the case of
read-only vs read-writable, the database has enough information to make
good decisions.
> Those files would need less than
> 10 zones or chunks, usually just one.
Agreed.
> 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.
I consider read-only vs. read-writable to be pretty one dimensional. And
the storage is logically organized in contiguous blocks. So there are
split points between segments with differing read-only property,
according to my definition.
Regards
Markus
