Re: Documentation improvements for partitioning

On Tue, Feb 21, 2017 at 2:03 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Mon, Feb 20, 2017 at 02:37:44PM +0530, Robert Haas wrote:
>> On Mon, Feb 20, 2017 at 2:09 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> > On 15 February 2017 at 15:46, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> >>> It leaves me asking what else is missing.
>> >>
>> >> There is certainly a lot of room for improvement here but I don't
>> >> understand your persistent negativity about what's been done thus far.
>> >> I think it's pretty clearly a huge step forward, and I think Amit
>> >> deserves a ton of credit for making it happen. The improvements in
>> >> bulk loading performance alone are stupendous. You apparently have
>> >> the idea that somebody could have written an even larger patch that
>> >> solved even more problems at once, but this was already a really big
>> >> patch, and IMHO quite a good one.
>> >
>> > Please explain these personal comments against me.
>>
>> Several of your emails, including your first post to this thread,
>> seemed to me to be quite negative about the state of this feature. I
>> don't think that's warranted, though perhaps I am misreading your
>> tone, as I have been known to do. I also don't think that expressing
>> the opinion that the feature is better than you're giving it credit
>> for is a personal comment against you. Where exactly do you see a
>> personal comment against you in what I wrote?
>
> I have to admit my reaction was similar to Simon's, meaning that the
> lack of docs is a problem, and that the limitations are kind of a
> surprise, and I wonder what other surprises there are.
>
> I am thinking this is a result of small teams, often from the same
> company, working on a features in isolation and then making them public.

I agree that this is result of small teams. The partitioning feature
encompasses features like global indexes, which is large in
themselves. Usually, in a company many teams would be working on
different sub-features in the same release schedule. But that's not
the case here. We have to add sub-features in multiple releases. That
might be the reason behind some of the current limitations.

> It is often not clear what decisions were made and why.

Amit Langote submitted the patch sometime in August 2015, which
certainly didn't look like a well-thought design, certainly not a
product of 'long cooking' within his company. It was more
experimental. (Obviously he had background of many earlier discussions
on partitioning, that all happened on hackers.) Since then all the
discussion is on hackers; all decisions were made during the
discussion. While what you are saying may be true with other patches,
I am not sure whether it's true with this work.

> The idea that
> unique indexes on a parent table can't guarantee uniqueness across child
> tables is both a surprise, and obvious once stated.

I think, that's a limitation till we implement global indexes. But
nothing in the current implementation stops us from implementing it.
In fact, I remember, a reply from Robert to another thread on
partitioning started in parallel to Amit's thread had explained some
of these design decisions. I am unable to find link to that exact
reply though.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company