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 1f1b3l-0004h2-Sa for pgadmin-hackers@arkaria.postgresql.org; Thu, 29 Mar 2018 17:09:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f1b3k-0001WC-Td for pgadmin-hackers@arkaria.postgresql.org; Thu, 29 Mar 2018 17:09:56 +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 1f1b1w-0000Wn-Or for pgadmin-hackers@lists.postgresql.org; Thu, 29 Mar 2018 17:08:05 +0000 Received: from mail-vk0-x229.google.com ([2607:f8b0:400c:c05::229]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1f1b1r-00023G-0A for pgadmin-hackers@postgresql.org; Thu, 29 Mar 2018 17:08:03 +0000 Received: by mail-vk0-x229.google.com with SMTP id m69so1773158vka.8 for ; Thu, 29 Mar 2018 10:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pivotal-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6qBoCV5uJsfWNQqF6bZ6E8YDs1LZ6CSKJ2uYSDlCw1Y=; b=yZOCylE50I/Mpvk/7gEvNzXZKUKgiKlkZDjdFk2Eiq52nj+qoOgV1ueOAG/wUDp1n0 sj6IpMfZWjBQ2maUWg+0JHrQAxqSCp/l5BBBfQKbSVYr7vSPKtCVkQ1Ixmar6UgKegGS ii8S3011/PrSpGGmH+G4lEueJ2TbhEep1UuHbvCR1HI/hVYPqEElqKmqT0t/oehHv6f7 w9bY65QQ1mhGbRTTkefitelwBw4na7Yoj0U/zxX4a3exQ6uwad1adgE2AOgDJkLGpQNB NvdLcyH+4nJndya82hTnru/oXjip+ZRSlvObVgp4coNW/0qjklxriQpgbuaUUfuV6ivV pK5A== 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=6qBoCV5uJsfWNQqF6bZ6E8YDs1LZ6CSKJ2uYSDlCw1Y=; b=Koi9kLQMnmyJEtYcQN1eEnEJFMg61U5VJL7mqm4LyIQnQnENeNvd0YKkKITRpEVsMe +6sthddoJeuzi+lDkUlkf/Gf+RYtCBEHNnq5o2XqCBT7Tlsn5r2da+lWbfpaDU5N2RW1 NytQJvn4Od7SRpRUJ6ksECRk9Lw7OeAe1631SgOoNFfYET7TqjIV+e3Zio3ujsoCQsWt t+gvvQQIO0NUOtl0YxfCDgH4v4kasQEA7SasjQ3ojLf9kOMIoVUQv09OnWhkzM3wGzLV SIeT9hjnipxHvbUuNVkJY6ktXLhe+cDD+LcnQ7vP6WMowmuP1kE6ArGID3f5wBjlP0Uz +DZQ== X-Gm-Message-State: AElRT7EP3d0WwA6ujCOaBZZOnfRKJqcvH3+59VTjuqNUqjynzTLwGaJZ IKVt6ikyqAqGfjANm4yqJfJtfGc69jg6ytF56Swx0A== X-Google-Smtp-Source: AIpwx48TNNfGJDiswj8CQ5j345jVRKPgmMYV2NKdqUdBzZMAbh1UPPDXUqwDIXvLlBsxKhQU+mgQ5IXYT/f2giZywjQ= X-Received: by 10.31.188.13 with SMTP id m13mr5704437vkf.86.1522343276234; Thu, 29 Mar 2018 10:07:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.96.136 with HTTP; Thu, 29 Mar 2018 10:07:55 -0700 (PDT) In-Reply-To: References: From: Robert Eckhardt Date: Thu, 29 Mar 2018 13:07:55 -0400 Message-ID: Subject: Re: [pgAdmin4][Patch]: RM #3180 Index node is missing from the tree view of the table node To: Murtuza Zabuawala Cc: Joao De Almeida Pereira , Akshay Joshi , pgadmin-hackers Content-Type: multipart/alternative; boundary="001a1143809234e1810568902aa9" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --001a1143809234e1810568902aa9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2018 at 12:45 PM, Murtuza Zabuawala < murtuza.zabuawala@enterprisedb.com> wrote: > Thanks Akshay & Joao, got it. > > My bad sorry for the noise. > The question helped me, nothing wrong with questions. -- Rob > > -- > Regards, > Murtuza Zabuawala > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > On Thu, Mar 29, 2018 at 9:06 PM, Joao De Almeida Pereira < > jdealmeidapereira@pivotal.io> wrote: > >> 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 (pop= ulation); >> >> 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 tes= ts >> around it. >> >> Thanks >> Joao >> >> On Thu, Mar 29, 2018 at 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 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 wha= t >>>> is called sub-partitioning. Partitions may have their own indexes, >>>> constraints and default values, distinct from those of other partition= s. >>>> Indexes must be created separately for each partition. See CREATE TABL= E >>>> for m= ore >>>> 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 r= efer >>> "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 = the >>>>> 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>* >>> >> > --001a1143809234e1810568902aa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 29, 2018 at 12:45 PM, Murtuza Zabuawala &= lt;= murtuza.zabuawala@enterprisedb.com> wrote:
Thanks Akshay & Joao, got it.

My bad sorry for the noise.

The question helped me, nothing wrong wit= h questions.=C2=A0

-- Rob
=C2=A0
= --
Regards,
Murtuza Zabuawala
EnterpriseDB:=C2=A0http://www.enterprisedb.com
The Enterprise PostgreSQL Company


On Thu, Mar 29= , 2018 at 9:06 PM, Joao De Almeida Pereira <jdealmeidapereira@p= ivotal.io> wrote:
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, 2= 018 at 6:36 PM, Murtuza Zabuawala <murtuza.zabuawala@ente= rprisedb.com> wrote:
<= div dir=3D"ltr">
Hi Akshay,

I have concerns regarding the fix, As you negate the conditi= on, Before the fix it was not displaying Index node for Tables but after th= e fix it will not display it for Partition tables.
But when I read the Postgres= docs it say,
Partitions may themselves be defined as part= itioned tables, using what is called=C2=A0sub-partitioni= ng. 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=C2=A0CREATE TABLE=C2=A0for more details on creating partitioned tables an= d partitions.

=C2=A0 =C2=A0 Yes tha= t is correct, but it's about Partitions(child tables), not the *Partiti= oned* table. We are showing indexes on Partitions. Please refer "Index= _on_Partitioned_table.png"=C2=A0 =C2=A0



--
Rega= rds,
Murtuza Zabuawala
EnterpriseDB:=C2=A0http://www.enterprisedb.com
The Enterprise PostgreSQL Company
<= /div>
<= br>

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

Please find the attac= hed patch to fix RM=C2=A0#3180=C2=A0<= span style=3D"font-size:12.8px">Index node is missing from the tree view of= the table node. This is a regression of one of the older commit.

--
Akshay Joshi
Sr. Software Architect
<= /font>

=

Phone: +91 2= 0-3058-9517
Mobile: +91 976-788-8246
<= /div>




--
Akshay Joshi<= /b>
= Sr. Software Architect




--001a1143809234e1810568902aa9--