Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3l2f-0003YH-RX for pgadmin-hackers@arkaria.postgresql.org; Thu, 27 Apr 2017 15:09:14 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d3l2f-0002pp-Cs for pgadmin-hackers@arkaria.postgresql.org; Thu, 27 Apr 2017 15:09:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d3l2e-0002pZ-Jq for pgadmin-hackers@postgresql.org; Thu, 27 Apr 2017 15:09:12 +0000 Received: from mail-it0-x22c.google.com ([2607:f8b0:4001:c0b::22c]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1d3l2Z-0000u5-TN for pgadmin-hackers@postgresql.org; Thu, 27 Apr 2017 15:09:11 +0000 Received: by mail-it0-x22c.google.com with SMTP id f187so13182911ite.1 for ; Thu, 27 Apr 2017 08:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B1Btc2qcqcR5N9xsL9gIk5Vldxkxp1DQ8w/knic3cM4=; b=A93jDtSLMV/tFso+6d5st63vpGrVJ1spUYsDRjEYltj7xm+HLQLjp5gKSMSizTYRCe RtMrsEjbntimY4eU5c/cLmDWaDY0fBAmbS4aVwrmQ5s3TLHsMOpWpVDab/qrr4wDCNcq MmWgUFAmwv6/pRjcVUQGNWpO+72snR4gkwcU/E17rGvHsP2Rg2ay1hSZvzlaWlD0EnIK e45AXt2BKm6IZkh/oFeOGPJA1/W0XNj+0D0ODZRpRshm6Mw7QH1liyVU2AjusvhzgjXQ 9jgHiyrrxSBKNyXQA9AN6Kt+p01EoyP+wMpg5ka5qFYNS9YCxadSSbbaKjOcb4ZaWiAI SZZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B1Btc2qcqcR5N9xsL9gIk5Vldxkxp1DQ8w/knic3cM4=; b=Ekclo6kfXLwIIUnK/SOhrsDIw651RYef/oMzoay+up0RzJOhU08q4d/c7yV7KvIh4F pXHDv8Q0bWpzbRaBPHTM/aaeTXK3CF9TFbC2n6gKT13JB0bzXeJf6fALwGN9uF+7VYbi Ll8ucMj+nuVUmWReGiQbmCU9Wg2H0hBLaa8Oj2V1YcQNOR9Sxzk44lhw39/tc+SsAPio qN6IwxTCy2BrrV8DFLoatZwT2oVw0dem43wB98bTly7mpUrSVjsj6Ff2vIVqVZo6cu9I xyJd2Ch/8QsjL1dPLzkCyEzcFN8nePuccp8DViY09z0SqnTT5L/Q9Tmn/Y0csVoOX2JO MhYQ== X-Gm-Message-State: AN3rC/43kSoPu3rj31UOYBdXGml2U7rMeUBvvVHmH3Tcynu4pYtaMm6Q sFLeP4lJwl9T6G3UEdjJb2zQj53ZDQ== X-Received: by 10.36.225.13 with SMTP id n13mr14793ith.85.1493305745972; Thu, 27 Apr 2017 08:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.174.167 with HTTP; Thu, 27 Apr 2017 08:09:05 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Thu, 27 Apr 2017 16:09:05 +0100 Message-ID: Subject: Re: Declarative partitioning in pgAdmin4 To: Akshay Joshi Cc: Shirley Wang , pgadmin-hackers Content-Type: multipart/alternative; boundary=94eb2c19d59c87bc87054e2756b5 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --94eb2c19d59c87bc87054e2756b5 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 27, 2017 at 12:01 PM, 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. > That's pretty much what I had in mind, yes. There are certain object types that would need to be rendered under the partitions themselves instead of the parent though. > > > On Thu, Apr 27, 2017 at 1:44 PM, Dave Page wrote: > >> >> >> On Wed, Apr 26, 2017 at 6:36 PM, Shirley Wang wrote: >> >>> Hello! >>> >>> On Wed, Apr 26, 2017 at 4:26 AM Dave Page wrote: >>> >>>> Hi >>>> >>>> [moving to the pgadmin-hackers mailing list as this a pgAdmin feature] >>>> >>>> On Wed, Apr 26, 2017 at 8:20 AM, Akshay Joshi < >>>> akshay.joshi@enterprisedb.com> wrote: >>>> >>>>> Hi Dave >>>>> >>>>> Murtuza and I started thinking about "How to add Declarative >>>>> Partitioning" support in pgAdmin4. We thought instead of showing Partition >>>>> Table under existing Tables collection, we should add new collection node >>>>> "Partition Tables". Showing table under the table node recursively will >>>>> require lots of code changes in table and it's child nodes (column, index, >>>>> trigger, etc..) which is more complex and error prone. >>>>> >>>> >>>> Perhaps, but from the user's perspective, there's no reason to list >>>> them separately - they are just tables with a different structure from >>>> others. We shouldn't confuse the user just because it's more convenient for >>>> us. >>>> >>>> I really think it should look like this: >>>> >>>> - Tables >>>> - t1 >>>> - Columns >>>> - Constraints >>>> - Partitions >>>> - p1 >>>> - Sub Objects (whatever they may be) >>>> ... >>>> - p2 >>>> ... >>>> - t2 >>>> ... >>>> >>>> >>> >>>> >>>>> >>>>> Below is the design that we can implement: >>>>> >>>>> - Create new "Partition Tables" collection node. User will be able >>>>> to create partition table by clicking "Create -> Partition Table" menu that >>>>> we will add on collection node. We will share the dialog prototype >>>>> later once we will have complete understanding of it. >>>>> >>>>> Can you share a mock-up of the dialog? The Figma tool that Shirley >>>> shared looks like it'll be good for doing that - I can invite you to the >>>> team. >>>> >>> >>>>> - Once table is created user will be able to create partitions by >>>>> clicking "Create -> Partitions" menu will be added on each partitioned >>>>> table node. We will share the dialog prototype later once we will >>>>> have complete understanding of it. >>>>> >>>>> I would expect the user to be able to define the partitioning scheme >>>> when they create the table; e.g. on a new tab. It shouldn't be a two step >>>> process. >>>> >>>>> >>>>> - We will have to show sub nodes like (column, index, trigger, >>>>> constraints, etc..) on main table while some of the sub nodes won't require >>>>> for partitions like (column and many more again require some more knowledge >>>>> on partitioning). >>>>> >>>>> OK. >>>> >>>> >>>>> Apart from above we will have to figure out following: >>>>> >>>>> - How to remove partitions(table) from existing tables node as >>>>> value of relkind column is 'r' for partitions. >>>>> - Partitioning scheme to show in SQL pane for partitions. >>>>> - Some unknown issue/features of Declarative partitioning. >>>>> >>>>> OK. >>>> >>> >>> Seems like there are a couple of assumptions being made here: >>> - Users need to see partitioned tables when expanding parent table >>> >> >> If by "assumption" you mean "fact", then yes :-). Users need to be able >> to see and manipulate partitions. Whilst some sub-objects are defined on >> the parent table (e.g. the columns), others are defined on the individual >> partitions (e.g. triggers, indexes). >> >> >>> - Users need to view partitioned tables in context to their parent table >>> (Dave says yes, Akshay and Murtuza say no) >>> >> >> That's not what was said. Akshay and Murtuza were proposing a new >> collection node, e.g. >> >> - Schema >> - Functions >> - Partitioned Tables >> - Tables >> - Views >> >> I'm saying that that unnecessarily complicates things for the user. The >> fact that a table happens to use declarative partitioning, doesn't make it >> a different type of object as far as Postgres is concerned, nor should it >> for us. >> >> >>> - Users want to create a partitioned table through the browser (Akshay >>> and Murtuza say yes, Dave says no) >>> >> >> I didn't say that. I said it shouldn't be a two-part process. >> >> >>> >>> Plus some technical concerns: >>> - Making code changes in table is complex and error prone >>> - How to move partitions from one node to another >>> >>> I think the first assumption is important to validate or invalidate >>> before even thinking about how to implement or addressing technical >>> concerns. We may come to learn that there are solutions that don't require >>> a lot of technical maneuvering, or perhaps learn there's no need for change >>> at all. >>> >> >>> Akshay and Murtuza, I'm happy to work with you on doing some research >>> (interviews to discover user needs and pains, creating mockups, getting >>> feedback etc) and coming up with some solutions based on user feedback. >>> >> >> How would users come up with feedback, given that the feature doesn't >> exist in the field yet? >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > > > > -- > *Akshay Joshi* > *Principal Software Engineer * > > > > *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91 976-788-8246 > <+91%2097678%2088246>* > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --94eb2c19d59c87bc87054e2756b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 12:01 PM, Akshay Joshi <akshay.jos= hi@enterprisedb.com> wrote:
Hi Dave

As per discussion I have chang= ed the logic of showing partitioned table in browser tree. Attached is the = screenshot.=C2=A0
Let me know your thoughts.

That's pretty much what I had in mind, yes. Th= ere are certain object types that would need to be rendered under the parti= tions themselves instead of the parent though.

=C2= =A0
=C2=A0=C2=A0<= /div>

On Thu, Apr 27, 2017 at 1:44 PM, Dave Page <dpage@pgadmin= .org> wrote:


On Wed, Apr 26, 2017 at 6:36 PM, Shirley = Wang <swang@pivotal.io> wrote:
Hello!

On Wed= , Apr 26, 2017 at 4:26 AM Dave Page <dpage@pgadmin.org> wrote:
Hi

[moving to the pga= dmin-hackers mailing list as this a pgAdmin feature]

On Wed, Apr 26, 2017 at 8:20 AM, Aks= hay Joshi <akshay.joshi@enterprisedb.com> w= rote:
Hi Dave

Murtuza = and I started thinking about "How to add Declarative Partitioning"= ; support in pgAdmin4. We thought instead of showing Partition Table under = existing Tables collection, we should add new collection node "Partiti= on Tables". Showing table under the table node recursively will requir= e lots of code changes in table and it's child nodes (column, index, tr= igger, etc..) which is more complex and error prone.=C2=A0

Perhaps, but from the user's perspective, t= here's no reason to list them separately - they are just tables with a = different structure from others. We shouldn't confuse the user just bec= ause it's more convenient for us.

I really thi= nk it should look like this:

- Tables
= =C2=A0 - t1
=C2=A0 =C2=A0 - Columns
=C2=A0 =C2=A0 - Con= straints
=C2=A0 =C2=A0 - Partitions
=C2=A0 =C2=A0 =C2= =A0 - p1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Sub Objects (whatever they= may be)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 = =C2=A0 - p2
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 - t2
<= div>=C2=A0 ...
=C2=A0 =C2=A0
=C2=A0

Below is the design that we= can implement:=C2=A0
  • Create new "Partition Tables&q= uot; collection node. User will be able to create partition table by clicki= ng "Create -> Partition Table" menu that we will add on collec= tion node.=C2=A0We will share the dialog prototype later once we will have complete understa= nding of it.
Can you share a mock-up= of the dialog? The Figma tool that Shirley shared looks like it'll be = good for doing that - I can invite you to the team.=C2=A0
=
  • Once table is created user= will be able to create partitions by clicking "Create -> Partition= s" menu will be added on each partitioned table node. We will share th= e dialog prototyp= e later once we will have complete understanding of it.
I would expect the user to be able to define the partit= ioning scheme when they create the table; e.g. on a new tab. It shouldn'= ;t be a two step process.=C2=A0
  • We will have to show sub nodes like (column, index, = trigger, constraints, etc..) on main table while some of the sub nodes won&= #39;t require for partitions like (column and many more again require some = more knowledge on partitioning).
OK.=
=C2=A0
=
Apart from above we will have to figure out following:
    <= li>How to remove partitions(table) from existing tables node as value of relkind column is &= #39;r' for partitions.
  • Partitioning scheme to show in SQL pane for partitions.<= br>
  • Some unknown issue/features of Declarative partitioning.=C2=A0<= /li>
OK.

Seems like there are a couple of assump= tions being made here:
- Users need to see partitioned tables whe= n expanding parent table

<= /div>
If by "assumption" you mean "fact", the= n yes :-). Users need to be able to see and manipulate partitions. Whilst s= ome sub-objects are defined on the parent table (e.g. the columns), others = are defined on the individual partitions (e.g. triggers, indexes).
=C2=A0
- Users need to view partitioned tables= in context to their parent table (Dave says yes, Akshay and Murtuza say no= )

That's not w= hat was said. Akshay and Murtuza were proposing a new collection node, e.g.=

- Schema
=C2=A0 - Functions
= =C2=A0 - Partitioned Tables
=C2=A0 - Tables
=C2=A0 - Vi= ews

I'm saying that that unnecessarily complic= ates things for the user. The fact that a table happens to use declarative = partitioning, doesn't make it a different type of object as far as Post= gres is concerned, nor should it for us.
=C2=A0
<= div>- Users want to create a partitioned table through the browser (Akshay = and Murtuza say yes, Dave says no)
=

I didn't say that. I said it shouldn't b= e a two-part process.
=C2=A0

Plus some technical concerns:
- Making code chan= ges in table is complex and error prone
- How to move partitions = from one node to another

I think the first assumpt= ion is important to validate or invalidate before even thinking about how t= o implement or addressing technical concerns. We may come to learn that the= re are solutions that don't require a lot of technical maneuvering, or = perhaps learn there's no need for change at all.

Akshay and Murtuza, I'm happy to work with = you on doing some research (interviews to discover user needs and pains, cr= eating mockups, getting feedback etc) and coming up with some solutions bas= ed on user feedback.

How would users come up with feedback, given that the feature doesn'= t exist in the field yet?=C2=A0

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQ= L Company


--
= Akshay Joshi
Principal Software Engine= er=C2=A0

=

+91 20-3058-9517
Mobile: +91 976-788-8246


--
Dave Page
Blog: = http://pgsnake.bl= ogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com<= br>The Enterprise PostgreSQL Company
--94eb2c19d59c87bc87054e2756b5--