Re: What needs to be done for real Partitioning?

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: What needs to be done for real Partitioning?
Date: 2005-03-22 08:34:22
Message-ID: 1111480462.11750.510.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sun, 2005-03-20 at 01:14 -0500, Greg Stark wrote:
> Josh Berkus <josh(at)agliodbs(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Layet Benjamin 2005-03-22 09:22:24 best practices with index on varchar column
Previous Message Greg Stark 2005-03-22 04:42:50 Re: What about utility to calculate planner cost constants?