Re: Syntax for partitioning
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Markus Wanner <markus@bluegap.ch>, Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>, pgsql-hackers@postgresql.org
Date: 2009-11-20T15:59:51Z
Lists: 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