Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nByU3-0007hW-4Z for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jan 2022 12:30:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nByU1-0001kD-DH for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jan 2022 12:30:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nByU1-0001k3-19 for pgsql-hackers@lists.postgresql.org; Mon, 24 Jan 2022 12:30:05 +0000 Received: from mxout2.routing.net ([2a03:2900:1:a::b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nByTx-0000II-Vs for pgsql-hackers@postgresql.org; Mon, 24 Jan 2022 12:30:04 +0000 Received: from mxbox1.masterlogin.de (unknown [192.168.10.88]) by mxout2.routing.net (Postfix) with ESMTP id 5609E5FD67; Mon, 24 Jan 2022 12:29:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailerdienst.de; s=20200217; t=1643027399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=o0ZI2+9hjZQEbEEc3/rm1XNzIwEBHu1T1Cci5cTtwr4=; b=vYLqs22Gq2NPLJcV9tSpsLYTgEuGU80uugLyox9SFOhZdiqgJDR4WRAyzsQniqU6olpgLY P68whvQ7EWerPJATK5Tr74GiNh8CvyM4noN6vepJmOuEutfILsM42U7cWeN2h36J6mOZpn 1CBCNbPWtITe8V1HZ1buZtPyigXB2qY= Received: from remote.index.de (i68970D96.versanet.de [104.151.13.150]) by mxbox1.masterlogin.de (Postfix) with ESMTPSA id B2E66404DF; Mon, 24 Jan 2022 12:29:58 +0000 (UTC) Received: from acedia.index-gruppe.local (192.168.54.121) by invidia.index-gruppe.local (192.168.54.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 24 Jan 2022 13:29:58 +0100 Received: from acedia.index-gruppe.local ([::1]) by acedia.index-gruppe.local ([fe80::651c:f2d9:e6f9:7444%13]) with mapi id 15.01.2308.021; Mon, 24 Jan 2022 13:29:58 +0100 From: Arne Roland To: Zhihong Yu CC: Alvaro Herrera , Julien Rouhaud , pgsql-hackers Subject: Re: missing indexes in indexlist with partitioned tables Thread-Topic: missing indexes in indexlist with partitioned tables Thread-Index: AQHXsJoeXw6ojQG4NkOLdiX4KUBdD6vkTOpcgIAWJQCAA2SO7oAAbRh////16wCAADDYxYAAo/oAgABsDQCAAiIn7oAADRXl///25gCAAD4kxg== Date: Mon, 24 Jan 2022 12:29:58 +0000 Message-ID: <937a0d27a72b4326a841f8a33a136ef5@index.de> References: <20220118065750.v5zigpuisljc6jmk@jrouhaud> <202201181324.idvthmrhbtf5@alvherre.pgsql>, In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.1.33] Content-Type: multipart/alternative; boundary="_000_937a0d27a72b4326a841f8a33a136ef5indexde_" MIME-Version: 1.0 X-Mail-ID: 696cb8c2-55f4-43a4-95c7-7866a2d5c9ad List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_937a0d27a72b4326a841f8a33a136ef5indexde_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! > From: Zhihong Yu > Subject: Re: missing indexes in indexlist with partitioned tables > > Hi, > > - if (indexRelation->rd_rel->relkind =3D=3D RELKIND_PARTITIONED= _INDEX) > + if (inhparent && (!index->indisunique || indexRelation->rd_re= l->relkind !=3D RELKIND_PARTITIONED_INDEX)) > > The check on RELKIND_PARTITIONED_INDEX seems to negate what the comment a= bove says: > > + * Don't add partitioned indexes to the indexlist > > Cheers The comment at my end goes on: /* * Don't add partitioned indexes to the indexlist, since they are * not usable by the executor. If they are unique add them to the * partindexlist instead, to use for further pruning. If they * aren't that either, simply skip them. */ Regarding the structure: I think, that we probably should remove the first = two sentences here. They reoccur 50 lines below anyways, which seems a dubi= ous practice. The logic that enforces the first two sentences is mainly dow= n below, so that place is probably on one to keep. Regarding the semantics: This is sort of what the statement checks for (ski= p for inhparent, if not unique or not partitioned index), i.e. it checks fo= r the case, where the index shouldn't be added to either list. Side note: I personally think the name inhparent is mildly confusing, since= it's not really about inheritance. I don't have a significantly better ide= a though. From: Alvaro Herrera Sent: Wednesday, January 19, 2022 23:26 > Ah, apologies, I didn't realize that that test was so new. No offense taken. Unless one was involved in the creation of the correspond= ing patch, it's unreasonable to know that. I like the second part of your m= essage very much: > See src/tools/ci/README (for multi-platform testing of patches on > several platforms) and http://commitfest.cputube.org/ Thanks, I didn't know of cputube. Neat! That's pretty much what I was looki= ng for! Is there a way to get an email notification if some machine fails (turns br= ight red)? For the threads I'm explicitly subscribed to, that would seem he= lpful to me. Regards Arne --_000_937a0d27a72b4326a841f8a33a136ef5indexde_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!

> From: Zhihong Yu <zyu@yugabyte.com>
> Subject: Re: missing indexes in indexlist with partitioned tables
>  
> Hi,
>
> -           if (inde= xRelation->rd_rel->relkind =3D=3D RELKIND_PARTITIONED_INDEX)
> +           if (= inhparent && (!index->indisunique || indexRelation->rd_rel-&g= t;relkind !=3D RELKIND_PARTITIONED_INDEX))
>
> The check on RELKIND_PARTITIONED_INDEX seems to negate what the commen= t above says:
>
> +           = ; * Don't add partitioned indexes to the indexlist
>
> Cheers

The comment at my end goes on:


/*  
* Don't add partitioned indexes to the indexlist, since they are
* not usable by the executor. If they are unique add them to the
* partindexlist instead, to use for further pruning. If they
* aren't that either, simply skip them.
*/

Regarding the structure: I think, that we probably should remove the f= irst two sentences here. They reoccur 50 lines below anyways, which seems a= dubious practice. The logic that enforces the first two sentences is mainl= y down below, so that place is probably on one to keep.

Regarding the semantics: This is sort of what the statement checks for= (skip for inhparent, if not unique or not partitioned index), i.e. it chec= ks for the case, where the index shouldn't be added to either list.

Side note: I personally think the name inhparent is mildly confusing, since it's not really about inheritance. I don't have a signif= icantly better idea though.

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Sent: Wednesday, January 19, 2022 23:26
> Ah, apologies, I didn't realize that that test was so new.

No offense taken. Unless one was involved in the creation of the correspond= ing patch, it's unreasonable to know that. I like the second part of your m= essage very much:

> See src/tools/ci/README (for multi-platform testing of patches on
> several platforms) and http://commitfest.cputube.org/

Thanks, I didn't know of cputube. Neat! That's pretty much what I was looki= ng for!
Is there a way to get an email notification if some machine fails (turns br= ight red)? For the threads I'm explicitly subscribed to, that would seem he= lpful to me.

Regards
Arne

--_000_937a0d27a72b4326a841f8a33a136ef5indexde_--