Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f1Zc3-0006nz-2q for pgadmin-hackers@arkaria.postgresql.org; Thu, 29 Mar 2018 15:37:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f1Zc1-0000r8-ID for pgadmin-hackers@arkaria.postgresql.org; Thu, 29 Mar 2018 15:37: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.89) (envelope-from ) id 1f1Zc1-0000qy-Bk for pgadmin-hackers@lists.postgresql.org; Thu, 29 Mar 2018 15:37:13 +0000 Received: from mail-it0-x244.google.com ([2607:f8b0:4001:c0b::244]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1f1Zbu-0008Pj-Vz for pgadmin-hackers@postgresql.org; Thu, 29 Mar 2018 15:37:11 +0000 Received: by mail-it0-x244.google.com with SMTP id k135-v6so8696606ite.2 for ; Thu, 29 Mar 2018 08:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pivotal-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AsZwthptQnGeuQ004j4IIyGIFCdO2dI5Uu0y+0E5T1I=; b=m0prbGfPpJBPmT8DsXuq1X9ivNJBWvVoJzZ0mR5pnuHGfFwJrHqDnzdMfXjEor4HmS mTRVDsMnT1omSQHY6LuFzKpIn6C87vrVSzxrb0USWFwB5ZpxyUSb1LswpCteBcTlwh5I qSi1stttuWE38GEtV8RJUYtG2B3Bo+v2PcupS+X/wz7W+jxOfBv/4Ah6Yi/koNy8QnU1 +nwbboAoEXDAW2hImcdRrkhrkz0iJKlKXSWOOGqcwARvQ93/aLKV6a40MzcjwuwgGpE5 KMhNlaUeRne0eswxAfkbcgJAZyErp8scG7xXBfPzI7KN2IJbV4S9axeZY739OnfOmfCb S2cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AsZwthptQnGeuQ004j4IIyGIFCdO2dI5Uu0y+0E5T1I=; b=NLWuBOdps9B/69d4sf5NJos2rHpr/eNl3cJwddP1nyCdhgsDTC8W6OkEebbjgaMM+Y teoQLmHxjUfFiUn4LFnAeJhV7O2AYEe466wQd0Vl/LUbFB+Md77/acWlZ37UHsjE3CQx Fc+50uwysMm9TdPyWKZcifUIsX8AdetpuHTZ8+0DFLtLjKOxP5/vkpZBiTAN/BEAF/UV E42Ml7574pK/HbLdnAJ3zRkieztSuGPL09DMGYVl5gHmcqqpGEszqkcTY1h+r6CEbHOE D7EnaxqHeHr32plN3ZXCocmcs5xU7UTpDxkOnp7hOPZ+k4Q8TdSbff7rdtV5dSC6woDb GXJQ== X-Gm-Message-State: AElRT7F6juJhlSFVValLYCjN+8yv+3dhUzGfR/zwLbANDAbqi75gyhOF tRhLwVvk6DofJQmZVySS2RXUh0dQ2+SdJeTC8aZ1mQ== X-Google-Smtp-Source: AIpwx48JQ4iaEwyuLrzedvDelD1j2xgp4jzt/PtjqULE5548J9zfWqD9EaGMGs/micmGqy9B/do18DdnMV6DjLyzXLE= X-Received: by 2002:a24:c281:: with SMTP id i123-v6mr8092607itg.146.1522337824094; Thu, 29 Mar 2018 08:37:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Joao De Almeida Pereira Date: Thu, 29 Mar 2018 15:36:53 +0000 Message-ID: Subject: Re: [pgAdmin4][Patch]: RM #3180 Index node is missing from the tree view of the table node To: Murtuza Zabuawala Cc: Akshay Joshi , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000003bc75705688ee53e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000003bc75705688ee53e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Murtuza, Lets imagine you have CREATE TABLE cities ( city_id bigserial not null, name text not null, population int ) PARTITION BY LIST (initcap(name)); CREATE TABLE cities_west PARTITION OF cities ( CONSTRAINT city_id_nonzero CHECK (city_id !=3D 0) ) FOR VALUES IN ('Los Angeles', 'San Francisco') PARTITION BY RANGE (population); CREATE TABLE cities_west_10000_to_100000 PARTITION OF cities_west FOR VALUES FROM (10000) TO (100000); =E2=80=8B You can only create an index in *cities_west_10000_to_100000* because postgresql assumes that *cities_west* is also a partitioned table. So the implementation looks correct, despite the fact that there are no tests around it. Thanks Joao On Thu, Mar 29, 2018 at 9:26 AM Akshay Joshi wrote: > Hi Murtuza > > On Thu, Mar 29, 2018 at 6:36 PM, Murtuza Zabuawala < > murtuza.zabuawala@enterprisedb.com> wrote: > >> Hi Akshay, >> >> I have concerns regarding the fix, As you negate the condition, Before >> the fix it was not displaying Index node for Tables but after the fix it >> will not display it for Partition tables. >> But when I read the Postgres docs it say, >> *Partitions may themselves be defined as partitioned tables, using what >> is called sub-partitioning. Partitions may have their own indexes, >> constraints and default values, distinct from those of other partitions. >> Indexes must be created separately for each partition. See CREATE TABLE >> for mor= e >> details on creating partitioned tables and partitions.* >> Ref: https://www.postgresql.org/docs/10/static/ddl-partitioning.html >> (Sec: 5.10.2) >> > > Yes that is correct, but it's about Partitions(child tables), not the > *Partitioned* table. We are showing indexes on Partitions. Please refer > "Index_on_Partitioned_table.png" > >> >> >> >> -- >> Regards, >> Murtuza Zabuawala >> EnterpriseDB: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >> >> On Thu, Mar 29, 2018 at 6:05 PM, Akshay Joshi < >> akshay.joshi@enterprisedb.com> wrote: >> >>> Hi Hackers, >>> >>> Please find the attached patch to fix RM #3180 Index node is missing >>> from the tree view of the table node. This is a regression of one of th= e >>> older commit. >>> >>> -- >>> *Akshay Joshi* >>> >>> *Sr. Software Architect * >>> >>> >>> >>> *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91 >>> 976-788-8246 <+91%2097678%2088246>* >>> >> >> > > > -- > *Akshay Joshi* > > *Sr. Software Architect * > > > > *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91 976-788-8246 > <+91%2097678%2088246>* > --0000000000003bc75705688ee53e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Murtuza,
Lets imagine you have
CREATE TABLE cities (
    city_id         bigserial not null,
    name         text not null,
    population   int
) PARTITION BY LIST (initcap(name));

CREATE TABLE cities_west
    PARTITION OF cities (
    CONSTRAINT city_id_nonzero CHECK (city_id !=3D 0)
) FOR VALUES IN ('Los Angeles', 'San Francisco') PARTITION =
BY RANGE (population);

CREATE TABLE cities_west_10000_to_100000
    PARTITION OF cities_west FOR VALUES FROM (10000) TO (100000);
=E2=80=8B

You can only create an index in cities_west_10000_to_10= 0000 because postgresql assumes that cities_west is also a parti= tioned table. So the implementation looks correct, despite the fact that th= ere are no tests around it.

Thanks
Joao<= /div>
On Thu, Mar 29, 2018 a= t 9:26 AM Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:
Hi Murtuza

On Thu, Mar 29, 2018 at 6:36 PM, Murtuza= Zabuawala <murtuza.zabuawala@enterprisedb.com> wrote:
Hi Akshay,

I have conc= erns regarding the fix, As you negate the condition, Before the fix it was = not displaying Index node for Tables but after the fix it will not display = it for Partition tables.
But when I read the Postgres docs it say,
Partitions may themselves be defined as partitioned tables, using what= is called=C2=A0sub-par= titioning. <= span style=3D"color:rgb(0,0,0);font-family:verdana,sans-serif;font-size:12.= 16px;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:= normal;text-align:left;text-indent:0px;text-transform:none;white-space:norm= al;word-spacing:0px;text-decoration-style:initial;text-decoration-color:ini= tial;float:none;display:inline">Partitions may have their own indexes, constraints and = default values, distinct from those of other partitions. Indexes must be created separately for each partit= ion. See= =C2=A0CREATE TABLE=C2=A0for more details on creating partitioned tables and= partitions.

=C2=A0 =C2=A0 Yes that is correc= t, but it's about Partitions(child tables), not the *Partitioned* table= . We are showing indexes on Partitions. Please refer "Index_on_Partiti= oned_table.png"=C2=A0 =C2=A0
<= div class=3D"gmail_extra">



=
--
Regards,
Murtuza Zabuawala
EnterpriseDB:=C2=A0h= ttp://www.enterprisedb.com
The Enterprise PostgreSQL Company
<= /font>


On Thu, Mar 29, 2018 at 6:05 PM, Akshay Josh= i <akshay.joshi@enterprisedb.com> wrote:
Hi H= ackers,

Please find the attached p= atch to fix RM=C2=A0#3180=C2=A0Index node is missing from the tree view of the = table node. This is a regression of one of the older commit.

--
<= div>
Akshay Joshi
Sr. Software Architect

=

=

=


--
<= div>
Akshay Joshi
Sr. Software Architect

=

=
--0000000000003bc75705688ee53e--