Re: What needs to be done for real Partitioning? - Mailing list pgsql-performance

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