MIME-Version: 1.0
In-Reply-To: 
 <CA+OCxozkEdTmVUtJEBdHT97EbiUK_+cwW+rv21tuHyxSnN3HOg@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>
 <CA+OCxozkEdTmVUtJEBdHT97EbiUK_+cwW+rv21tuHyxSnN3HOg@mail.gmail.com>
From: Robert Eckhardt <reckhardt@pivotal.io>
Date: Thu, 27 Apr 2017 11:44:43 -0400
Message-ID: 
 <CAAtBm9UHyp+bkxcyYL+1qb9knps_cdh6N0tvwMy5uY-eVjWcPg@mail.gmail.com>
Subject: Re: Declarative partitioning in pgAdmin4
To: Dave Page <dpage@pgadmin.org>
Cc: Akshay Joshi <akshay.joshi@enterprisedb.com>,
 Shirley Wang <swang@pivotal.io>,
	pgadmin-hackers <pgadmin-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary=001a114e56eef9ead8054e27d5c4
Precedence: bulk
Sender: pgadmin-hackers-owner@postgresql.org

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

>
> 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.
>

Certainly there differences in Postgres and Greenplum and this might very
well be one of those places.


> I don't see that we have any choice but to display them so users can work
> with them.
>

We don't want to hide them, I do think we want to make accessing them a
useful experience. If we rephrase this statement as "How might we display
partitioned tables so that users are able to work with and modify the
pieces they need?", this opens us up to different opportunities in how we
display them.

Even with a simple case of 90 days of data partitioned by day, a drop down
showing 90 tables that are all mostly the same is a little overwhelming.


>
>>    - 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)?
>

Honestly I'm not sure. We didn't really start thinking about this until the
other day so we are starting to look into the pains that Greenplum
customers have. Sharing that pain we discover back to the pgAdmin community
and seeing if it makes sense from a Postgres perspective.  After that I
need to dive into the Postgres implementation.

-- Rob

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>The=
 issues we consistently face:<br></div><div><ul><li>The huge (often thousan=
ds sometimes tens of thousands) number of partitions makes rendering all of=
 the partitions painfully slow and frequently not useful.</li></ul></div></=
div></div></div></blockquote></span><div>Perhaps, though I doubt that numbe=
r would be common in Postgres. The problem though, is that there are both s=
tats and sub-objects (indexes and triggers for example) that are part of th=
e child partitions, not the parent - and they may differ from partition to =
partition. </div></div></div></div></blockquote><div><br></div><div>Certain=
ly there differences in Postgres and Greenplum and this might very well be =
one of those places.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div>I don&#39;t see that we have any choice but to display them so users =
can work with them.<br></div></div></div></div></blockquote><div><br></div>=
<div>We don&#39;t want to hide them, I do think we want to make accessing t=
hem a useful experience. If we rephrase this statement as &quot;How might w=
e display partitioned tables so that users are able to work with and modify=
 the pieces they need?&quot;, this opens us up to different opportunities i=
n how we display them.</div><div><br></div><div>Even with a simple case of =
90 days of data partitioned by day, a drop down showing 90 tables that are =
all mostly the same is a little overwhelming.=C2=A0</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div></div><span class=3D""><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><div><ul><li>When end users are interested in looking at their partit=
ions they frequently don&#39;t want all of them displayed mindlessly=C2=A0<=
/li><ul><li>They are looking at a subset of partitions</li><li>Partitions a=
re typically grouped around their inheritance properties.=C2=A0</li></ul></=
ul></div></div></div></div></blockquote></span><div>How might you propose g=
rouping them (based on the way they work in Postgres)?=C2=A0<br></div></div=
></div></div></blockquote><div><br></div><div>Honestly I&#39;m not sure. We=
 didn&#39;t really start thinking about this until the other day so we are =
starting to look into the pains that Greenplum customers have. Sharing that=
 pain we discover back to the pgAdmin community and seeing if it makes sens=
e from a Postgres perspective.=C2=A0 After that I need to dive into the Pos=
tgres implementation.=C2=A0</div><div><br></div><div>-- Rob</div></div></di=
v></div>

--001a114e56eef9ead8054e27d5c4--