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

From Simon Riggs
Subject Re: What needs to be done for real Partitioning?
Date
Msg-id 1111480462.11750.510.camel@localhost.localdomain
Whole thread Raw
In response to Re: What needs to be done for real Partitioning?  (Greg Stark <gsstark@mit.edu>)
List pgsql-performance
On Sun, 2005-03-20 at 01:14 -0500, Greg Stark wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>
> > -- INSERT INTO should automatically create new partitions where necessary
> >     ---- new tables should automatically inherit all constraints, indexes,
> >             keys of "parent" table
>
> I think you're going about this backwards.

Certainly, there are two schools of thought here. I have been in two
minds about which those two designs previously, and indeed here which
one to support.

> Phase I should be an entirely manual system where you add and remove
> partitions manually and create and drop indexes you want manually. You need
> these low level interfaces anyways for a complete system, it doesn't make
> sense to have everything automatic and then later try to wedge in a low level
> interface. Only once you have that do you then start offering options to do
> these things automatically.

Maybe its just me, but ISTM that implementing an automatic system is
actually easier to begin with. No commands, no syntax etc. You're right,
you need the low level interfaces anyway...

> From my experience with Oracle I think there's one big concept that makes the
> whole system make a lot more sense: individual partitions are really tables.
> The partitioned tables themselves are just meta-objects like views.

Hmmm. Oracle provides a very DBA-intensive implementation that as Stacy
points out, many people still do not understand. It does work, well. And
has many of the wrinkles ironed out, even if not all of them are easy to
understand why they exist at first glance.

I think it most likely that Phase I should be a simplified blend of both
ideas, with a clear view towards minimum impact and implementability,
otherwise it may not make the cut for 8.1

Best Regards, Simon Riggs


pgsql-performance by date:

Previous
From: Greg Stark
Date:
Subject: Re: What about utility to calculate planner cost constants?
Next
From: "Layet Benjamin"
Date:
Subject: best practices with index on varchar column