| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:18:34 |
| Message-ID: | 574381BA.1080202@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 05/23/2016 03:05 PM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
>> 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.
I wonder if it wouldn't make sense to define a partition as a list of
segments within a single table that represent the partition?
But then again, maybe we need to start with a clear notion of what
problems people are trying to solve when they use partitions. At least
some of the historic reasons are no longer valid.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-05-23 22:26:24 | Re: Inheritance |
| Previous Message | Tom Lane | 2016-05-23 22:05:39 | Re: Inheritance |