Re: Table Partitioning, Part 1

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, pgsql-hackers(at)postgresql(dot)org, bizgres-general <bizgres-general(at)pgfoundry(dot)org>
Subject: Re: Table Partitioning, Part 1
Date: 2005-05-10 22:40:05
Message-ID: 1115764805.3830.232.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2005-05-10 at 15:01 -0400, Tom Lane wrote:
> "Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> > On Tue, May 10, 2005 at 12:16:17AM +0100, Simon Riggs wrote:
> >> On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
> >>> I disagree. The code is there, it could use work, and what you are
> >>> basically proposing is to duplicate both the existing work and much
> >>> of the improvement it needs.
> >>
> >> Minefields need clearing someday, I suppose.
> >>
> >> Multiple inheritance isn't something I'll be spending time on though.
>
> > I'm also not sure that inheritance would support all cases.
>
> My point seems to have been widely misunderstood ;-)
>
> I was not suggesting that partitioning must be built on top of
> inheritance, nor vice versa, nor that they need to support exactly
> the same feature sets. What I am saying is that if you adopt an
> NIH attitude to the existing code, you are going to end up with a
> lot of duplication. There is a substantial amount of potentially
> common infrastructure, as well as common problems that you might as
> well solve for both cases at once. (Remember the inventor's paradox:
> the more general problem is often easier to solve.) In particular,
> the planning problems look essentially the same to me, as does the
> indexing problem.

Agreed - no worries.

I was already seeing that I can't solve all of the Bizgres use cases at
once, so its time for me to pick one and make that work. If I can do at
least one in a way that solves a general case problem, then I'm happy to
do it that way. We may learn something during the journey about the best
approach for the other use cases.

...and at least we would have something to put into 8.1

Best Regards, Simon Riggs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-05-10 22:55:39 Re: Oracle Style packages on postgres
Previous Message Greg Sabino Mullane 2005-05-10 22:38:48 Re: Views, views, views: Summary of Arguments