From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Jan Johansson <jan(dot)johansson(dot)mr(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inheritance |
Date: | 2016-05-23 22:05:39 |
Message-ID: | 29157.1464041139@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2016-05-23 22:18:34 | Re: Inheritance |
Previous Message | Joe Conway | 2016-05-23 21:58:51 | Re: Changed SRF in targetlist handling |