Re: Inheritance

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Inheritance
Дата
Msg-id 29157.1464041139@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Inheritance  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Inheritance  (Joe Conway <mail@joeconway.com>)
Re: Inheritance  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 5/23/16 11:05 AM, Merlin Moncure wrote:
>> This feature was very much a product of the time, at the height of the
>> "Object Relational" fad.  The trend for postgres has been in the exact
>> opposite direction, towards the SQL standard.  Further complicating
>> matters, inheritance has been repurposed to be the foundation for
>> table partitioning, making heavy changes problematic.

> I don't see why partitioning complicates fixing these issues. ISTM it's 
> the exact same complaint for both inheritance and partitioning.

My feeling about it is that we need to provide a partitioning feature
that doesn't rely on the current notion of inheritance at all.  We've
heard from multiple users who want to use large numbers of partitions,
enough that simply having a separate relcache entry for each partition
would be a performance problem, never mind the current approach to
planning queries over inheritance trees.  So the partitions need to be
objects much simpler than full-fledged tables.

If we had that, and encouraged people to migrate simple partitioning
use-cases to it, that might take off enough pressure that we could
afford to consider more-complicated inheritance schemes rather than
treating inheritance as an unfortunate legacy design.  But we're
some years away from being able to do that.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: Changed SRF in targetlist handling
Следующее
От: Joe Conway
Дата:
Сообщение: Re: Inheritance