Re: Syntax for partitioning
| От | Robert Haas |
|---|---|
| Тема | Re: Syntax for partitioning |
| Дата | |
| Msg-id | 603c8f070911200759w29d5d28kc294259c75346fc7@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Syntax for partitioning (Simon Riggs <simon@2ndQuadrant.com>) |
| Список | 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 по дате отправления: