MIME-Version: 1.0
In-Reply-To: 
 <CAAtBm9Ve2FX4_jY9tv11UqK2BhNoLn118aeT4y=TieSAovL+AA@mail.gmail.com>
References: 
 <CANxoLDcZND0pjXtrDKRip2xjddzjWiMgY2AMmrqqFE_Yu4+tHw@mail.gmail.com>
 <CA+OCxowUuaNRX9jHmEVFpqT7JCbjn6vaxw+JJ6yrvVp69FZscg@mail.gmail.com>
 <CAPG3WN5NY-Xsa_+6HUQ3NMU_n7jRgJ8L6rjHfyzSLSHS=zZC0Q@mail.gmail.com>
 <CA+OCxoy1v+mq2P4ZL2v7mmyHmjwQmL=v8RR8CSRra_SV96nJDQ@mail.gmail.com>
 <CANxoLDeBGRmq_kUUNNySXimzJO2Ebj0aQBdjNM+0JvP3_Yr9Dw@mail.gmail.com>
 <CAAtBm9Ve2FX4_jY9tv11UqK2BhNoLn118aeT4y=TieSAovL+AA@mail.gmail.com>
From: Dave Page <dpage@pgadmin.org>
Date: Thu, 27 Apr 2017 16:11:54 +0100
Message-ID: 
 <CA+OCxozkEdTmVUtJEBdHT97EbiUK_+cwW+rv21tuHyxSnN3HOg@mail.gmail.com>
Subject: Re: Declarative partitioning in pgAdmin4
To: Robert Eckhardt <reckhardt@pivotal.io>
Cc: Akshay Joshi <akshay.joshi@enterprisedb.com>,
 Shirley Wang <swang@pivotal.io>,
	pgadmin-hackers <pgadmin-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary=001a1137949e9d0092054e2760ed
Precedence: bulk
Sender: pgadmin-hackers-owner@postgresql.org

--001a1137949e9d0092054e2760ed
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 27, 2017 at 3:18 PM, Robert Eckhardt <reckhardt@pivotal.io>
wrote:

>
>
> On Thu, Apr 27, 2017 at 7:01 AM, Akshay Joshi <
> akshay.joshi@enterprisedb.com> wrote:
>
>> Hi Dave
>>
>> As per discussion I have changed the logic of showing partitioned table
>> in browser tree. Attached is the screenshot.
>> Let me know your thoughts.
>>
>
> Greenplum has had declarative partitioning for quite some time, I haven't
> spent much time diving into the Postgres implementation specifically,
> however, we have had some pain and I would suggest a little bit of thought
> behind this.
>
> The issues we consistently face:
>
>    - The huge (often thousands sometimes tens of thousands) number of
>    partitions makes rendering all of the partitions painfully slow and
>    frequently not useful.
>
> Perhaps, though I doubt that number would be common in Postgres. The
problem though, is that there are both stats and sub-objects (indexes and
triggers for example) that are part of the child partitions, not the parent
- and they may differ from partition to partition. I don't see that we have
any choice but to display them so users can work with them.

>
>    - When end users are interested in looking at their partitions they
>    frequently don't want all of them displayed mindlessly
>       - They are looking at a subset of partitions
>       - Partitions are typically grouped around their inheritance
>       properties.
>
> How might you propose grouping them (based on the way they work in
Postgres)?


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--001a1137949e9d0092054e2760ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Apr 27, 2017 at 3:18 PM, Robert Eckhardt <span dir=3D"ltr">&lt;=
<a href=3D"mailto:reckhardt@pivotal.io" target=3D"_blank">reckhardt@pivotal=
.io</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=
=3D"">On Thu, Apr 27, 2017 at 7:01 AM, Akshay Joshi <span dir=3D"ltr">&lt;<=
a href=3D"mailto:akshay.joshi@enterprisedb.com" target=3D"_blank">akshay.jo=
shi@enterprisedb.com</a><wbr>&gt;</span> wrote:<br></span><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Hi Dave<div><br></div><span class=3D""><div>=
As per discussion I have changed the logic of showing partitioned table in =
browser tree. Attached is the screenshot.=C2=A0</div><div>Let me know your =
thoughts. =C2=A0=C2=A0</div></span></div></blockquote><div><br></div><div>G=
reenplum has had declarative partitioning for quite some time, I haven&#39;=
t spent much time diving into the Postgres implementation specifically, how=
ever, we have had some pain and I would suggest a little bit of thought beh=
ind this.=C2=A0</div><div><br></div><div>The issues we consistently face:</=
div><div><ul><li>The huge (often thousands sometimes tens of thousands) num=
ber of partitions makes rendering all of the partitions painfully slow and =
frequently not useful.</li></ul></div></div></div></div></blockquote><div>P=
erhaps, though I doubt that number would be common in Postgres. The problem=
 though, is that there are both stats and sub-objects (indexes and triggers=
 for example) that are part of the child partitions, not the parent - and t=
hey may differ from partition to partition. I don&#39;t see that we have an=
y choice but to display them so users can work with them.<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><div><ul><li>When end users are interested in looking at=
 their partitions they frequently don&#39;t want all of them displayed mind=
lessly=C2=A0</li><ul><li>They are looking at a subset of partitions</li><li=
>Partitions are typically grouped around their inheritance properties.=C2=
=A0</li></ul></ul></div></div></div></div></blockquote><div>How might you p=
ropose grouping them (based on the way they work in Postgres)?=C2=A0<br></d=
iv></div><br clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signat=
ure" data-smartmail=3D"gmail_signature">Dave Page<br>Blog: <a href=3D"http:=
//pgsnake.blogspot.com" target=3D"_blank">http://pgsnake.blogspot.com</a><b=
r>Twitter: @pgsnake<br><br>EnterpriseDB UK: <a href=3D"http://www.enterpris=
edb.com" target=3D"_blank">http://www.enterprisedb.com</a><br>The Enterpris=
e PostgreSQL Company<br></div>
</div></div>

--001a1137949e9d0092054e2760ed--