Re: Syntax for partitioning - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Syntax for partitioning
Date
Msg-id 603c8f070911200759w29d5d28kc294259c75346fc7@mail.gmail.com
Whole thread Raw
In response to Re: Syntax for partitioning  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Fri, Nov 20, 2009 at 2:08 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Thu, 2009-11-19 at 10:53 -0500, Robert Haas wrote:
>> On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner <markus@bluegap.ch> wrote:
>> > Hi,
>> >
>> > Robert Haas wrote:
>> >>
>> >> Settling on a syntax, and an internal representation for that syntax,
>> >
>> > I've been under the impression that this was only about syntax. What are the
>> > internal additions?
>>
>> I haven't looked at it in detail, but it adds a new pg_partition
>> table.  Whether that table is suitably structured for use by the
>> optimizer is not clear to me.
>
> If it does, then my review comments to Kedar still apply:
>
> * why do we want another catalog table? what's wrong with pg_inherits?
> It might need additional columns, and it certainly needs another index.

That might work, I haven't looked at it enough to be sure one way or the other.

> * We need an internal data structure (discussed on this thread also).
> Leaving stuff in various catalog tables would not be the same thing at
> all.

Ultimately I'm guessing that for query optimization we'll need to
include the relevant info in the relcache.  But I think that can wait
until we're ready to actually make the optimizer changes - not much
point in caching data that is never used.  Right now I think it's
enough to verify (which I haven't) that the schema of the catalog
table is suitable for straightforward construction of the data that
will eventually need to be cached.

...Robert


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Summary and Plan for Hot Standby
Next
From: Robert Haas
Date:
Subject: Re: DEFAULT of domain ignored in plpgsql (8.4.1)