Re: What needs to be done for real Partitioning?

Tom, Stacy, Alvaro,

> I'd rather see the partition control stuff as ALTER TABLE commands,
> not decoration on CREATE TABLE. See the WITH OIDS business we just went
> through: adding nonstandard decoration to a standard command isn't good.

OK, sure.

> > -- INSERT INTO should automatically create new partitions where necessary
> > -- DELETE FROM should automatically drop empty partitions
>
> I am not sure I agree with either of those, and the reason is that they
> would turn low-lock operations into high-lock operations.

For INSERT, I think that's a problem we need to work through. Partitioning
on any scheme where you have to depend on the middleware to create new
partitions could never be more than a halfway implementation. For one thing,
if we can't have 100% dependence on the idea that Table M, Partition 34
contains index values Y-Z, then that form of advanced query rewriting (which
is a huge performance gain on really large tables) becomes inaccessable.

Or are you proposing, instead, that attempts to insert beyond the range raise
an error?

> DELETE FROM
> would be particularly bad. Furthermore, who wants to implement DROP
> PARTITION as a DELETE FROM? ISTM the whole point of partitioning is to
> be able to load and unload whole partitions quickly, and having to
> DELETE all the rows in a partition isn't my idea of quick.

I mostly threw DELETE in for obvious symmetry. If it's complicated, we can
drop it.

And you're right, I forgot DROP PARTITION.

> This is a bad idea. Where are you going to create these automatic
> tablespaces? What will they be named? Won't this require superuser
> privileges? And what's the point anyway?

Stacy White suggests the more sensible version of this:
ALTER TABLE {table} CREATE PARTITION WITH VALUE {value} ON TABLESPACE
{tablespacename}. Manually creating the partitions in the appropriate
location probably makes the most sense.

The point, btw, is that if you have a 2TB table, you probably want to put its
partitions on several seperate disk arrays.

> Huh? ISTM this confuses establishment of a table's partition rule with
> the act of pre-creating empty partitions for not-yet-used ranges of
> partition keys.

I don't understand why this would be confusing. If INSERT isn't creating
partitions on new value breakpoint, then CREATE PARTITION needs to.

> Or are you trying to suggest that a table could be
> partitioned more than one way at a time? If so, how?

No.

> - Modify the partitioning scheme of a table. In the above example, adding
> a '200504' partition, and moving the '200502' orders into 'ARCHIVE'

Hmmm ... I don't see the point in automating this. Can you explain?

> - Global indexes (that is to say, an index spanning the the table rather
> than an individual partition). This seems counterintuitive, but they've
> dramatically increased performance on one of our Oracle systems and should
> at least be worth considering.

Hmmm, again can you detail this? Maybe some performance examples? It seems
to me that global indexes might interfere with the maintenance advantages of
partitioning.

> We probably also need multi-table indexes. Implementing these would be
> good for inheritance too.

They would be nice, but I don't see them as a requirement for making
partitioning work.

--
Josh Berkus
Aglio Database Solutions
San Francisco