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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Summary and Plan for Hot Standby
Следующее
От: Robert Haas
Дата:
Сообщение: Re: DEFAULT of domain ignored in plpgsql (8.4.1)