Re: Table Partitioning, Part 1 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Table Partitioning, Part 1
Date
Msg-id 23378.1115751695@sss.pgh.pa.us
Whole thread Raw
In response to Re: Table Partitioning, Part 1  ("Jim C. Nasby" <decibel@decibel.org>)
Responses Re: Table Partitioning, Part 1  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
"Jim C. Nasby" <decibel@decibel.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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Oracle Style packages on postgres
Next
From: Thomas Hallgren
Date:
Subject: Re: Oracle Style packages on postgres